WBCE CMS Forum

WBCE CMS – Way Better Content Editing.

Du bist nicht angemeldet.

#1 19.08.2015 19:52:17

norhei
Developer

Sorry, aber das geht gar nicht!

Als Twig einfach fest im Core verdrahtet wurde, ohne überhaupt jemanden zu fragen empfand ich das schon als ziemlich Frechheit, mal flux das Branding ändern ohne vorher drüber zu sprechen ist auch nicht wirklich toll hab ich mich ja noch geschlossen gehalten aber jetzt werden auch noch die mit Absicht hinzugefügten Tools rausgeworfen ohne ein Wort zu verlieren und ein formatierungs Standard hintenrum eingeführt, über den auch noch keiner gesprochen hat. Ich empfinde das als absolute unmöglich. Einfach seine eigenen Lieblings Dinge einzubauen ohne überhaupt zu fragen oder Dinge die andere Eigebaut haben einfach kommentarlos zu entfernen, damit habe ich ein Riesenproblem.

Ich weiß nicht was die anderen dazu Denken aber das ist wenn überhaut Florians Projekt und zumindest der müsste gefragt werden, besser wäre es allerdings die Änderungen zu Diskussion zu stellen, bevor man sie ausführt.

Beitrag geändert von norhei (19.08.2015 19:55:05)

Offline

#2 19.08.2015 20:12:04

norhei
Developer

Re: Sorry, aber das geht gar nicht!

Nachtrag: Bugfixes , und ein paar Fileheader sind überhaupt kein Problem. Aber sobald es um Entscheidungen geht die wirklich die Zukunft betreffen, oder die Änderungen die Andere bereiz vorgenommen haben müssen wir uns alle verpflichten, es entweder öffentlich im Forum zu diskutieren  oder im anderen Fall mit denen zu sprechen, die es gemacht haben. Ansonsten funktioniert das nicht.

Offline

#3 19.08.2015 20:39:13

easyuser
Mitglied

Re: Sorry, aber das geht gar nicht!

Die meisten dieser Änderungen wurden aber im Forum "vorher" bekanntgegeben bzw. diskutiert, siehe z.B. Formatierung: https://forum.wbce.org/viewtopic.php?pid=743#p743
Das mit den Tools und Rebranding war jeweils eine "größere" Diskussion, finde sie aber grade nicht.

Allerdings ist es etwas schwer hier, die einzelnen Diskussionen nachzuvollziehen, weil diese an unterschiedlichen Stellen stattfinden.
Zudem finden ja noch Diskussionen auf github in den issues statt.

Ich würde vorschlagen, die größeren Änderungen jeweils in einem gesonderten Bereich vom Initiator mit einem extra Topic vorzustellen.
Dann ein paar Tage warten und dann reinpflegen oder eben nicht.

Aber: Man kann Änderungen ja auch rückgängig machen. Und es ist jetzt der Beginn, man muss das richtige Marschtempo erst noch finden.

Offline

#4 19.08.2015 20:58:48

cwsoft
Mitglied

Re: Sorry, aber das geht gar nicht!

@norhei: Standards wurden angesprochen. In dem Thread habe ich auch klar gestellt, dass es wenn es nicht gefällt leicht wieder geändert werden kann. Dachte auch dass eine einheitliche Formatierung in Deinem Sinne ist, da Du ja auch in einem Thread festgestellt hast dass Diffs bei unterschiedlichen Tabs, Whitespace die eigentlichen Änderungen ziemlich verdecken können.

Was die Tools betrifft. Dachte nicht dass es ein Problem ist, wenn ich die Tools in ein eigenes Repo verschiebe. Ich habe ja nix gelöscht, es ist alles noch da. Denke aber solche Tools wie ein ausgewachsener PHP Filemanager sollten nicht ins Standadpacket von WBCE. Die Zielgruppe kopiert einfach alles hoch, inkl. Ordner wbce und tools und passt Notfalls den Pfad im Backend von Plesk an. Dann wundern die sich wie es Hacker schaffen den Webspace zu übernehmen, da sie das Zeugs im tools Ordner schlicht vergessen haben.

Da es bereits konsens war, dass AFE und Code2 wegen Sicherheitsbedenken rausfliegen, habe ich mir beim Verschieben nicht gross was bei gedacht.

Würde aber nie im Traum darauf kommen, Änderungen die ein anderer gemacht hat, rückgängig zu machen. Was die Dateiheader betrifft, da hattest Du im Forum geschrieben dass Du es nicht schlecht findest, den Header bei Dateien an denen wir etwas geändert haben zu erneuern. Genau das habe ich gemacht und zwar nachdem ich ein Beispiel gepostet habe und ich noch von Dir vorgeschlagene Änderungen wie z.B. GPL 2 oder grösser etc. nachgebessert habe.

Wir können aber gerne meine letzten 5 Commits rückgängig machen. Wenn Du Dir, oder ein anderer Mitstreiter auf den Schlips getreten fühlst, das war nicht meine Absicht. Dann einfach hier posten und ich mache die Commits rückgängig.

Nachtrag: Und Twig in den Core, da habe ich mir nu wirklich keine grossen Gesanken gemacht. Der Autoloader war schon fest in WB eingebaut und diese Massnahme ermöglichte es in zwei mitgelieferte Addons zwei Kopien von Twig (mit AFE drei Kopien) aus dem Downloadpacket zu schmeissen. Dreimal Twig verlängert die Uploadzeit per FTP nicht unerheblich.

Aber bin mir sicher, wir werden das richtige Tempo und auch die Absprachen im Laufe der Zeit noch verbessern :-)

Beitrag geändert von cwsoft (19.08.2015 21:24:48)


Account inactive since 2018/11/17.

Offline

#5 19.08.2015 21:24:38

norhei
Developer

Re: Sorry, aber das geht gar nicht!

Allerdings ist es etwas schwer hier, die einzelnen Diskussionen nachzuvollziehen, weil diese an unterschiedlichen Stellen stattfinden.
Zudem finden ja noch Diskussionen auf github in den issues statt.
Ich würde vorschlagen, die größeren Änderungen jeweils in einem gesonderten Bereich vom Initiator mit einem extra Topic vorzustellen.
Dann ein paar Tage warten und dann reinpflegen oder eben nicht.

Ja, das wäre Klasse !!!! Und das ist auch der Punkt worum es geht!

Wegen Twig , da wäre eigentlich noch Diskussionsbedarf, aber nicht hier. Grundsätzlich hätte ich sie auch erst einmal eingebaut um Dir und einigen anderen das Leben leichter zu machen, wäre aber sehr dafür eine Schnittstelle zu machen, die andere TE auch ermöglicht , und ob da das BE darauf laufen sollte, weis ich nicht. Aber da machen wir besser einen extra Thread für auf.

AFE und Code2, ja war konsens , das war gut gelaufen, genauso sollte es !

Die Standards waren nur der Auslöser der mich zum Post veranlasst hat , eigentlich nicht wirklich wichtig. Wäre aber schön gewesen vorher zu fragen: "Was haltet ihr davon, ich nehme einen Code Beautifier und stelle alles auf PSR-2, Was denkt Ihr ?" Vermutlich hätten wir alle gesagt: schöne Idee. Und ich hätte vermutlich sogar vorgeschlagen das einfach vor jedem Release nochmal durchlaufen zu lassen.

Die Zielgruppe kopiert einfach alles hoch, inkl. Ordner wbce und tools und passt Notfalls den Pfad im Backend von Plesk an. Dann wundern die sich wie es Hacker schaffen den Webspace zu übernehmen, da sie das Zeugs im tools Ordner schlicht vergessen haben.

Ganz so doof sind die meisten auch ned und es läuft so auch garnicht, aber wenn Du einen besseren Vorschlag als einen full featured Editor , dann immer her damit. Aber ich finde das sowas wie Admin PW zurücksetzen und Template zurücksetzen, sowie Dateien löschen, schon ins Paket gehören. Der Changelog Generator muss nicht der könnte genauso wie ein Tool für die Sprachdateien vielleicht in ein extra Dev Paket.
Überigens hat BC den Ordner deswegen "upload" genannt, gute Idee finde ich!


Lange Rede kurzer Sinn, last uns drüber reden!

Offline

#6 19.08.2015 21:33:05

cwsoft
Mitglied

Re: Sorry, aber das geht gar nicht!

@norhei: Yo, vorher diskutieren ist super. Dann gerne auch vorab ob wir nen ausgewachsenen PHP Filemanager im Packet mitliefern wollen etc. tongue

Wie gesagt, es ist nu wies ist. Wenn es wirklich vorbehalte wegen Twig, Dateiheadern, Formatierung und dem verschieben der Tools in ein exta Repo gibt, einfach Meinung dazu hier posten. Ich mache die Änderungen gerne alle oder teilweise rückgängig.


Account inactive since 2018/11/17.

Offline

#7 19.08.2015 21:36:39

florian
Administrator

Re: Sorry, aber das geht gar nicht!

Hallo,

mein Senf dazu
- Umbenennung wb -> wbce finde ich gut

- Auslagern der riskanten Tools -> unbedingt und auf jeden Fall!
Ich tendiere auch dazu, davon auszugehen, dass sowas sonst aus Versehen mit hochgeladen wird.  Ich habe in den letzten 8 Jahren WB-Benutzung vielleicht 3x diese Notanker gebraucht. Es ist gut, dass es so etwas gibt, und ich kann sie im AOR ergänzen, sie haben aber im Standardinstallationspaket nichts zu suchen. Das sind hochriskante Backdoors, die wirklich nur für Profis sind. WBCE gesamt ist _nicht_ nur für Profis.

- wegen Twig hatte ich letztens eine Anfrage, da hatte ein übersensibles Intrusion-Checking false positive geliefert, und ich sehe es auch mit Sorge, dass der Installer von WBCE schon ganz schön groß ist. Ich kann das fachlich nicht beurteilen, aber wenn Twig nicht unbedingt gebraucht wird, wäre es besser, dieses standardmäßig nicht mitzuliefern sondern als Library/Modul ggf. nachträglich bei Bedarf installieren zu können.


Code allein macht nicht glücklich. Jetzt spenden!

Offline

#8 20.08.2015 05:56:14

cwsoft
Mitglied

Re: Sorry, aber das geht gar nicht!

@Florian: bezüglich Dateigrösse des Installers. Wenn wir Twig als Lib oder Modul anbieten und erstmal auslagern, müssten auch Stefeks Tools wieder raus, die verwenden beide Twig, wie alle meine Module: Anynews, Postits, AFE. Oder wir machen wieder die Standardmodule von Stefek und mir rein, die bringen jeweils ihre eigene Kopie von Twig mit, was aber dem Ziel eines schlanken Installers wiederspricht.

WB-Classic hat Twig bereits seit SVN 1643 (WB 2.8.3 SP2) für Modulentwickler fest integriert und es wird automatisch geladen, wenn man es in den vorgesehenen Ordner schiebt. Da wir ja möglichst kompatibel zu WB bleiben wollen, habe ich diesen Weg der Integration gewählt. Habe auch kein Problem damit, Twig als Modul oder sonstwas anzubieten. Aber das wäre erstmal mehr Arbeit gewesen, hätte uns weiter von WB-Classic entfernt und das Problem mit nem schlankeren Installationspacket auch nicht gelöst, da drei ursprünglich mithelieferte Module eh ihr eigenes Twig mitbrachten.

Beitrag geändert von cwsoft (20.08.2015 05:57:55)


Account inactive since 2018/11/17.

Offline

#9 20.08.2015 07:19:54

norhei
Developer

Re: Sorry, aber das geht gar nicht!

@norhei: Yo, vorher diskutieren ist super. Dann gerne auch vorab ob wir nen ausgewachsenen PHP Filemanager im Packet mitliefern wollen etc. tongue

Hast Du völlig recht .
Wobei ich nicht gedacht hätte das möglicherweise jemand so blöd ist das mit hochzuladen.

Deswegen mehr Kommunikation :-)

Habe die Tools wesentlich öfter gebraucht, weswegen ich auch gerne die Rudimentären mit dabei hätte. Der Editor kann besser in ein Entwickler Paket.

Was Twig betrifft, um Gottes willen erst mal drin lassen bis wir dafür eine Schnittstelle haben, es sei dann wir wollen uns allen das Leben schwer machen 

Wir müssen einfach noch etwas besser kommunizieren ! Frage ist jetzt: neues Board , oder wo machen wir das ?

Noch was zu dem Platzbedarf:

Modules: 7,2 mb davon  5mb alleine der CKeditor
Andere CMS liefern hier teilweise gar nichts mit.

Includes: 3,5 mb davon Yui fast 900kb, Jquery fast 900kb, Twig grade mal knapp 500kb  idna konvert und php Mailer haben zusammen schon 550kb 
Yui rauswerfen, jquery über ein CDN laden und gut die Hälfte an Platz sparen. Nebenbei stehen hier auch noch eine ganze Sammlung von alten Jqueries und eine Jquery UI drinn . Wird die UI im BE überhaupt genutzt ? Obendrein ist Quickskin rausgeflogen und dafür Twig rein. Übrigens muss man der ollen PhpLib eines lassen, mit 35 kb ist sie wirklich Platzsparend im Gegensatz zu den 500 kb von Twig


Templates: 2,8 mb aber, 2 Admin Themes  , 3 Beispiel Themes
Andere CMS liefern hier auch oft garnichts (1Admin Theme). Zusätzlich könnte man auch hier Jquery UI, jquery, und Font Awesome über CDN laden.

Offline

#10 20.08.2015 07:30:55

cwsoft
Mitglied

Re: Sorry, aber das geht gar nicht!

norhei schrieb:

Wir müssen einfach noch etwas besser kommunizieren ! Frage ist jetzt: neues Board , oder wo machen wir das ?

Ich wäre für neues Board, z.B. "Core-Entwickler Discussions". Da könnten wir dann wie von Easyuser vorgeschlagen geplante Änderungen vorab vorstellen (Pros-, Cons) und 2-3 Tage auf Feedback warten, bevor wir grössere Änderungen am Core vornehmen.

Wobei es sicherlich Anfangs grenzwertig ist, was nun ne grössere Core Änderung bedeutet und was nicht. Da müssen wir uns halt finden.

Für mich war z.B. die Änderung der Sprachdateien (Thread: Die Putze hat zugeschlagen) eine kleine Modifikation, der PHP Dateimanager ne grössere (zumindest für unbedarfte Benutzer). Aber ich denke solche Sachen können dann im Thread diskutiert werden und dann ins Repo geladen werden.

Nachtrag:
Was ich gerne mache (hängt aber von der Konfiguration des Hosters ab) ist folgendes:
Kleinen Installer hochladen (wenige kB), der das ZIP von der eingetragenen Stelle runterlädt und mit PHP auf dem Webspace entpackt.

Vorteil: Rasend schnell, da keine einzelnen Dateien per FTP übertragen werden müssen.
Nachteil: Bei schlecht konfigurierten Hostern (z.B. all-inkl.) kann es zu Berechtigungsproblemen kommen (Gruppen für PHP und FTP User). Bei Domainfactory (gut konfiguriert) wähle ich praktisch immer diesen Weg, auch für Updates von Coredateien etc. Man könnte die Berechtigung auch vorab im Installer prüfen und nur bei gut konfigurierten Hostern diese Option anbieten, sonst den Weg über FTP vorschlagen.

Beitrag geändert von cwsoft (20.08.2015 07:36:36)


Account inactive since 2018/11/17.

Offline

#11 20.08.2015 07:33:24

norhei
Developer

Re: Sorry, aber das geht gar nicht!

Nachtrag: Wir liefern alleine schon fast 1mb an Sprachdateien mit , in anderen CMS ist meist nur eine Dabei.
Die würden allerdings drastisch eindampfen wenn die ganzen Entities wegfallen.

Und im Framework ist der größte Teil die charsets_table.php, wofür wird die eigentlich benutzt ?

Offline

#12 20.08.2015 07:36:30

norhei
Developer

Re: Sorry, aber das geht gar nicht!

Genau , im Zweifelsfalle kurz fragen, das wär toll. Was hälst eigentlich davon den Ordner nicht wbce sondern wirklich upload zu nennen , das dürfte die Menge der "Unfälle" deutlich verkleinern.

Offline

#13 20.08.2015 09:43:14

florian
Administrator

Re: Sorry, aber das geht gar nicht!

Ich habe ein Board dafür eingerichtet
Core Developer Discussion


Code allein macht nicht glücklich. Jetzt spenden!

Offline

#14 20.08.2015 09:54:06

florian
Administrator

Re: Sorry, aber das geht gar nicht!

norhei schrieb:

7,2 mb davon  5mb alleine der CKeditor

Kennt jemand einen schlankeren WYSIWYG-Editor? CKE entwickelt sich ja wirklich immer mehr zur Bloatware.

norhei schrieb:

Andere CMS liefern hier teilweise gar nichts mit.

Das mag so sein, sollte aber für uns kein Vorbild sein. WBCE soll idealerweise "out of the box" funktionieren. Ich weiß, das ist ein Widerspruch - schlanker Installer und größtmöglicher Funktionsumfang - aber so lange wir nicht bei Piwik-Dimensionen landen...

norhei schrieb:

Was Twig betrifft, um Gottes willen erst mal drin lassen bis wir dafür eine Schnittstelle haben, es sei dann wir wollen uns allen das Leben schwer machen

Ja, natürlich. Das war auch von mir nur eher so ein allgemeiner Gedanke. Wenn alle Module, die Twig benutzen, es selbst mitbringen, wird es ja auch noch mehrfach installiert, sodass damit nichts gewonnen ist.

cwsoft schrieb:

Was ich gerne mache (hängt aber von der Konfiguration des Hosters ab) ist folgendes:
Kleinen Installer hochladen (wenige kB), der das ZIP von der eingetragenen Stelle runterlädt und mit PHP auf dem Webspace entpackt.

Das ist aber riskant, denn dann ist es für Hacker extrem attraktiv, zu versuchen, an das Zip heranzukommen und so unbemerkt reihenweise Neuinstallationen zu verseuchen.
Ich mache es immer so, aus den Dateien im Verzeichnis wbce ein Zip zu packen, und das zusammen mit einem kleinen PHP-Script zum Entpacken hochzuladen.
Bei All-Inkl muss man halt PHP auf CGI umstellen (.htaccess) oder mit dem Dateibesitzer-Tool hin- und herschalten.


Code allein macht nicht glücklich. Jetzt spenden!

Offline

#15 20.08.2015 09:59:26

webbird
Administrator

Re: Sorry, aber das geht gar nicht!

Schön, machen wir es doch anders: Jeder zieht sich bei GitHub seinen eigenen Fork und macht dort seine Änderungen. Anschließend werden die als Pull Requests zur Übernahme gestellt. Diese können dann hier diskutiert und gemeinschaftlich "abgesegnet" werden. Vielleicht bringt das etwas mehr Disziplin und Stringenz in das Projekt.

Ständig Änderungen rein-raus-rein-raus sehen nach außen nach totalem Chaos aus.


Ich habe eine Amazon-Wishlist. wink Oder spende an das Projekt.
Ich kann, wenn ich will, aber wer will, dass ich muss, kann mich mal

Offline

#16 20.08.2015 10:02:44

webbird
Administrator

Re: Sorry, aber das geht gar nicht!

Übrigens, ohne jetzt stänkern zu wollen, aber so chaotisch war es weder bei LEPTON noch bei BlackCat, wobei man bei BC noch argumentieren kann, daß wir ja auch nur zu zweit sind. Bei L* waren es immerhin 5 Entwickler (plus 1 Möchtegern), aber da wurde vorher durchgesprochen, was gemacht wird und wer was macht, und erst dann wurde gehandelt. Ich würde diese Vorgehensweise auch hier wärmstens empfehlen.


Ich habe eine Amazon-Wishlist. wink Oder spende an das Projekt.
Ich kann, wenn ich will, aber wer will, dass ich muss, kann mich mal

Offline

#17 20.08.2015 10:04:10

cwsoft
Mitglied

Re: Sorry, aber das geht gar nicht!

webbird schrieb:

Ständig Änderungen rein-raus-rein-raus sehen nach außen nach totalem Chaos aus.

Naja, das kam jetzt zweimal vor.

Ob wir wirklich die PSR-2 (Whitespace, Einrückung) Commits, die Dateiheader Commits (Branding der von uns bereits angefassten Dateien) und die WBCE-Tools Auslagerungs-Commits rückgängig machen, steht noch gar nicht fest.

Denke Norhei war "zurecht" etwas sauer, dass das ohne vorherige "explizite" Nachfrage geschah. Das kann man mit dem Core Diskussions Thread auch lösen. Ich würde mal schauen ob wir damit die Sache in den Griff bekommen, wenn nicht kann man immer noch Fork/Pull einführen.


Account inactive since 2018/11/17.

Offline

#18 20.08.2015 10:09:03

florian
Administrator

Re: Sorry, aber das geht gar nicht!

Ich sehe das ehrlich gesagt noch nicht so dramatisch, verfolge die Entwicklung auf github aber auch zugegebenermaßen nicht mit. Von chaotisch möchte ich nicht sprechen. Im übrigens ist es doch super, das was passiert, und dass es transparent passiert - nicht so wie bei WB classic, wo sich entweder gar nichts bewegt oder nur im stillen Kämmerlein.

Ich habe doch jetzt das Core-Entwickler-Board eingerichtet.  (Bei FluxBB ist es leider extrem aufwändig, eine Poll-Funktion zu ergänzen. Wenn sich das wer antun will, PM an mich, ich habe jedenfalls diesbezüglich das Handtuch geworfen.)


Code allein macht nicht glücklich. Jetzt spenden!

Offline

#19 20.08.2015 10:12:10

webbird
Administrator

Re: Sorry, aber das geht gar nicht!

Persönlicher Rat von mir: Verzettelt Euch nicht! Es ist völlig egal, ob Code mit 2 oder 4 Leerzeichen oder Tabs eingerückt ist, so lange er _überhaupt_ eingerückt ist. Und auch, ob eine Variable groß, klein, CamelCase, mit Unterstrich oder sonstwie geschrieben ist, ist völlig nebensächlich, so lange der Name was über sie aussagt. (Doof: $r, besser: $result) Und vor allem: Hört auf, Code zu befummeln, den andere aus anderen Gründen auch gerade befummeln, und das nur, weil er Euch nicht hübsch genug ist. Wenn man eine Datei anfaßt, um _wirklich_ _inhaltlich_ was damit zu machen, und sie dann vorher mal durch einen Code Beautifier schiebt, weil einem das angebracht erscheint - okay. Aber nur befummeln um des Befummelns willen finde ich unnötigen Aktionismus.

Es ist nachvollziehbar, daß sich im WB-Umfeld vieles aufgestaut hat, aber so kriegt Ihr das nicht in den Griff. Das hier ist mein 3. Fork, ich weiß, wovon ich rede.


Ich habe eine Amazon-Wishlist. wink Oder spende an das Projekt.
Ich kann, wenn ich will, aber wer will, dass ich muss, kann mich mal

Offline

#20 20.08.2015 10:29:52

norhei
Developer

Re: Sorry, aber das geht gar nicht!

Das kann man mit dem Core Diskussions Thread auch lösen. Ich würde mal schauen ob wir damit die Sache in den Griff bekommen, wenn nicht kann man immer noch Fork/Pull einführen.

Denke auch , das das ein Versuch wert ist !
Ich denke das Chaos ist ein Resultat dessen, das wir alle seit Jahren und ziemlich zurück gehalten haben und gerne den alten Müll schnell los würden.
Das Gefühl, das es jetzt zu chaotisch wird hat mich ja veranlasst den Thread hier zu beginnen.

Und den Code Beautifier einmal drüber zu jagen, ist auf jeden Fall besser als das Chaos vorher. Egal ob mit Tabs oder Spaces, Tabs find ich halt nur praktischer am Anfang der Zeile, schlimmstenfalls muss ich kurz ein paar Einstellungen am Editor ändern und beim entfernen halt 4 mal drücken.
Damit kann ich leben. Würde mich trotzdem über Tabs am Zeilenanfang freuen wink

Also nichts rückgängig machen, sondern nur nächstes Mal kurz vorher Bescheid sagen.

Offline

#21 20.08.2015 13:13:28

cwsoft
Mitglied

Re: Sorry, aber das geht gar nicht!

webbird schrieb:

Persönlicher Rat von mir: Verzettelt Euch nicht! Wenn man eine Datei anfaßt, um _wirklich_ _inhaltlich_ was damit zu machen, und sie dann vorher mal durch einen Code Beautifier schiebt, weil einem das angebracht erscheint - okay. Aber nur befummeln um des Befummelns willen finde ich unnötigen Aktionismus.

Der unnötige Aktionismus hat in Sublimetext 3 fünf Minuten gedauert. Mir ist auch egal, ob Einrückungen 2 oder 4 Leerzeichen oder gar mit Tabs geschehen. Nur ist der WB-Code an vielen Stellen kaum mehr lesbar. Falsche Klammersetzung oder falsche Einrücktiefen verschleiern auch oft die Logik etwas komplexeren Blöcke. Norhei auch schon angemerkt, dass es beim Vergleich von Dateiänderungen über GitHub es oft schwierig ist die eigentliche Codeänderungen nachzuvollziehen, da auch unterschiedlicher Whitespace hervorgehoben wird.

Das war übrigens der Auslöser für mich 5 Minuten zu investieren und den PHP-Code zumindest mal grundlegend zu formatieren. Ich persönlich habe meinen Editor so eingestellt, dass er automatisch beim speichern formatiert, oder mit CTRL+F11. Und das andere Zeugs wie Variablendeklaration etc. Hier ging es darum zu erfragen, ob jeder sich mit PRS-1 bzw. PRS-2 Standards zufrieden stellt und dies dann für NEU hinzugefügten Code implementiert.

Das grossflächige "Refaktorisieren" von bestehendem Legacy Code empfinde ich als Overkill ohne grossen Mehrwert für den Endanwender. Die schauen nämlich nicht in den Code.

Beitrag geändert von cwsoft (20.08.2015 13:13:45)


Account inactive since 2018/11/17.

Offline

#22 20.08.2015 22:18:17

cwsoft
Mitglied

Re: Sorry, aber das geht gar nicht!

cwsoft schrieb:

Was ich gerne mache (hängt aber von der Konfiguration des Hosters ab) ist folgendes:
Kleinen Installer hochladen (wenige kB), der das ZIP von der eingetragenen Stelle runterlädt und mit PHP auf dem Webspace entpackt.

florian schrieb:

Das ist aber riskant, denn dann ist es für Hacker extrem attraktiv, zu versuchen, an das Zip heranzukommen und so unbemerkt reihenweise Neuinstallationen zu verseuchen.  Ich mache es immer so, aus den Dateien im Verzeichnis wbce ein Zip zu packen, und das zusammen mit einem kleinen PHP-Script zum Entpacken hochzuladen.

Und wo bekommst Du die WBCE-ZIP Datei her? Von der WBCE Homepage? Verstehe nicht warum Deine Methode dann sicherer sein soll als die von mir genannte. Wenn der Hacker das Installer-Script der WBCE-Homepage ändern kann, kann er auch das ZIP-Packet dort manipulieren. So geschehen bei WB-Classic, SourceForge, Notepad++ und einigen anderen.

Eventuell habe ich aber auch einen Denkfehler.

Beitrag geändert von cwsoft (20.08.2015 22:20:53)


Account inactive since 2018/11/17.

Offline

#23 21.08.2015 08:32:23

florian
Administrator

Re: Sorry, aber das geht gar nicht!

Auch wieder wahr.
Es ist wahrscheinlich nur ein subjektiver Mulm, der mich immer beschleicht, wenn von irgendwo™ was nachgeladen wird, ohne dass ich sehe, was da passiert.
Das einzige Argument, was mir einfällt ist, dass es eventuell schneller auffällt, wenn die Dateien manipuliert wurden - wenn im lokal entpackten Zip zusätzliche Dateien mit merkwürdigen Namen sind oder das Änderungsdatum abweicht. Manche Virenscanner kennen auch PHP-Trojaner und ähnliches und schlagen Alarm. Aber die meisten Hacker sind sicherlich klug genug, ihre Angriffe zu verschleiern, sodass die genannten Punkte nur gegen unbedarfte Scriptkiddies helefen würden.

Einen Expressinstaller mit dem Hinweis darauf, welche Bedingungen serverseitig erfüllt sein müssen, bzw. dass dieser evtl. nicht überall funktioniert, wäre durchaus eine gute Idee, das will ich ja gar nicht bestreiten.


Code allein macht nicht glücklich. Jetzt spenden!

Offline

#24 21.08.2015 09:40:15

norhei
Developer

Re: Sorry, aber das geht gar nicht!

Sicherheit ist immer unbequem ;-)

Ein Installer der Nachläd bietet ein klein wenig mehr Angriffsfläche aber das ist nicht wirklich schlimm. ein Installer der alles nachläd funktioniert aber auf ettlichen Webspaces nicht (kein fopen oder Curl, Laufzeit zuende ....) Und selbst der der nur entpackt , kann in die Laufzeitbeschränkung rennen.


So ein Installer kann praktisch sein, aber man muss immer auch alternativ das Paket zum DL anbieten.

Beitrag geändert von norhei (21.08.2015 09:42:04)

Offline

#25 21.08.2015 09:41:34

norhei
Developer

Re: Sorry, aber das geht gar nicht!

Für Profis könnte man auch noch Composer unterstützen ...

Offline

Fußzeile des Forums

up