vBulletin 4 - der Stand der Dinge - aktuell: 4.2.2

[Titus]

naja ein paar Infos sind mir da auch zu Ohren gekommen, sehe das aber nur bedingt kritisch, bzw harre der Dinge

als Kunde ist es mir letztendlich relativ egal wer an dem Teil schraubt, interessant ist das es funktioniert und meinen Wünschen gerecht wird!
manchmal mag das auch zur Folge haben, dass eben ein neues Feature Schrott ist, oder schlicht nicht ankommt, bisher habe ich als Admin da aber noch die Kontrolle meine User damit zu konfrontieren, oder eben drauf zu verzichten bis es was taugt bzw auch nie, sollte ich es nicht für brauchbar ersinnen

Manche Entscheidungen mögen aus Entwicklersicht idiotisch sein! Als relativ "dümmlicher" Anwender sage ich Dir aber, ich pfeife auf OO-Programmierung (und trauere jetzt schon den eval($Hook); nach), Barrierefreiheit geht mir am Hintern vorbei (BTW auch im wBB kann ich nicht ohne Maus arbeiten und z.B. mit dem Tabulator navigieren)

Tabellenlayouts stören mich auch nicht, was eher nervt sind lange Ladezeiten (z.b. prad.de) oder ne daraus resultierende CPU-Last (mir ist klar das es nicht jeden dort betrifft und wohl mit der Werbung zusammen hängt, trozdem scheint es ein wenig mit dem Board in Zusammenhang zu stehen)
das mag bei jemand der tiefer in der Materie steckt anders sein, aber ich vermute das die Wenigsten sich über das hinter den Kulissen Gedanken machen, anders könnte man glückliche Windowsbenutzer und Appleuser nicht erklären - so lange es läuft, schert sich kaum einer um das warum

 

[rellek]

Jo so ähnlich sehe ich das auch. Zudem finde ich, dass Tabellendesigns auf mobilen Browsern den Vorteil haben, dass man schon akzeptable Ergebnisse sieht, bevor der CSS-Code geladen wird.

Hm und OOP ist ja ausschließlich für Entwickler interessant. Das interessiert den Betreiber gar nicht und den Endanwender noch weniger, der will ja nur labern.

 

[Hawkes]

Der Betreiber sollte sich für sowas interessieren, falls er Entwickler engagiert, die mit der Plattform entwickeln müssen. Es wird nämlich für den Betreiber dann relativ teuer, wenn die unter der Hauptsoftware liegende Technik nix taugt.

Insofern empfehle ich euch etwas mehr Weitsicht und etwas weniger Ignoranz

 

[Titus]

nur brauch (besser will) ich keine Entwickler, ich such mir entweder vorhandene Addons zusammen, oder gehe zu einer Software wo ich das nicht brauche, bzw die Addons bekomme die mir vorschweben

sollte ich mir dann doch was einbilden haben zu müssen, läuft das wie folgt:
bei vB (und damals phpBB) suche ich mir das Template wo was machen soll, den Code in den PHP-Dateien der dafür zuständig ist, dann die nächstgelegene Hookstelle und frickel das ein was ich brauche (was ich auch zusammen bekomme, selbst wenn das ne Klasse oder Funktion ist)

bei wBB und eigentlich auch IPB3 schau ich (und ich sage mal das ich zumindest ein wenig verstehe was passiert) nur wie dumm Schwein ins Uhrwerk und ärger mich das es nicht geht <- ergo Software für mich nicht wirklich Interessant, wenn ich nicht mit dem was es ab Werk gibt, oder _sicher_ in Addonform bekommen kann, auskomme!

das wird sich sicher bei mir irgendwann ändern (wenn mir keine Wahl bleibt und mich damit befassen muss ^^)

ich will jetzt keine Grundsatzdiskussion führen sondern nur erläutern wie es mir in Zusammenhang mit Forensoftware aus eher "nicht IT-Futzi"-Sicht geht, vielleicht interessiert das ja einen der Herren Entwickler wenn ihn mal wieder das Verhalten des komischen Kunden nur wunder bringt
Außerdem denke ich kaum einer sucht sich nen guten Coder (oder einen der sich dafür hält), sondern benzt in den Foren so lange bis er bekommt was er will, bzw geht angep*sst hin wo ers bekommt
Ein großteil der Admins ist vermutlich mit dem entpacken einer tar.gz auf nem Windowssystem annähernd überfordert, geschweige denn eine XML lesen und verstehen was da passieren soll. Vielleicht noch anhand eines fertigen Plugins der Community mittels ein wenig tüfteln verstehen was da eigentlich vorgeht ganz zu schweigen.
Somit wird die Anzahl derer welche Code beisteuern (und sei er auch grausam beschi**en) immer kleiner - vielleicht legt man auch die Latte einfach höher um diese auszusortieren, welche eh nur per Copy&Paste Hacks fabrizieren - bei vB geht das halt (noch) mit PHP4 Wissen einfach, der Plugineditor im ACP tut den Rest :thumbsup:

sogar bei IPB kann ich im ACP den Hooktyp, nebst weiterführender Optionen und natürlich auszuführende Code-Datei einkleistern. Wobei da wieder gestehe ohne Auswahl des wer/wie/wo/wann Eventpunkts übersteigt das mein Verständnis aktuell auch (was mich wieder zum 3ten Absatz bringt, kein Frickelcode, aktuell nicht meine Baustelle)

das mit der "ignoranz" gebe ich damit zurück ins Entwicklerlager nur weil euch einer abgeht muss ich darauf keinen gesteigerten Wert legen

BTW:
vielleicht kann mir jemand den selben Code einfach kürz in wBB3 form übersetzten wie er so ein "qick&dirt" lösen würde

Situation, ich möchte ein wenig HTML Code der dynamisch kurz vor der Ausgabe der Seite an den Browserclient erstellt wird im Header positionieren,
beim vB erstelle ich ein Plugin auf Hook "global_complete"

$myhtmlstring = '';
# some code
if ($myhtmlstring) {
$output = str_replace( '', $myhtmlstring.'' , $output);
}

$output ist bei vB an der Stelle der gesamte Quellcode der dann am Browser ankommt

 

[Hawkes]

Für diesen speziellen Fall gibt es mehrere Arten an Plugins in der WCom, aber Marke Eigenbau:

Dies würde mit einem Eventlistener gelöst werden. Es gibt verschiedene Platzhalter wo du das unterbringen kannst. Wenn es um den Header geht, dann wäre das additionalHeaderContents.

Dein Scriptbit hätte als Eventlistener folgendes aussehen (da ich es direkt hier im Editor tippe verzeiht ihr mir bitte das unschöne Codeformat):

<?php
// wcf imports
require_once(WCF_DIR.'lib/system/event/EventListener.class.php');

class MyHeaderListener implements EventListener {
public function execute($eventObj, $className, $eventName) {
// hier wird der Platzhalter/Hook erweitert. Anstatt des statischen Inhalts kann hier nun natürlich die Ausgabe dynamisch erzeugt werden
WCF::getTPL()->append('additionalHeaderContents', '

Hello, World!</p>');
}
}
?>

Da man im WCF unter KEINEN Umständen Codehacking verwenden sollte, da man sich das bei Updates sonst wieder wegballert, muss der Eventlistener nun dem System bekannt gemacht werden. Bei einem Paket gibt es dazu das entsprechende XML-PiP. Manuell geht das, indem man einen entsprechenden Eintrag der wcfX_event_listener Tabelle hinzufügt und dann den Cache leert.

Beim Eventlistener kannst du mir wohl kaum sagen, dass das zu kompliziert ist. Die Registrierung dürfte für die meisten schon eher das Problem darstellen, was aber in der Doku beschrieben ist. Außerdem hat dieses Verfahren einfach einen riesigen Vorteil: Es ist updatesicher und es kommt zu keinen Konflikten mit anderen Plugins.

Ansonsten schreibe ich mal nichts weiter, mir fehlt für eine detaillierte Antwort die Zeit, aber dein Post untermauert eben, dass auf Adminseite die Weitsicht fehlt und ich mich da Frage, ob die Grundeignung des technischen Admins hier erfüllt ist. Immer vorrausgesetzt, dass wir von einem großen, professionell konzeptioniertem Forum sprechen.

 

[GameR]

Situation, ich möchte ein wenig HTML Code der dynamisch kurz vor der Ausgabe der Seite an den Browserclient erstellt wird im Header positionieren,
beim vB erstelle ich ein Plugin auf Hook "global_complete"
...
$output ist bei vB an der Stelle der gesamte Quellcode der dann am Browser ankommt

Was mit vB4 wegfällt.

 

[Sebastian]

Das ist echt traurig, was sich die von vBulletin codemäßig leisten ;( .

Seit ich mit dem WCF arbeite, habe ich das Problem, dass ich fast keine anderen PHP-Skripts mehr einsetze, da sie einfach so altmodisch programmiert sind. So sehr ich auch die freie Arbeit schätze, für mich kommt ein Einsatz von z.B. Joomla, Typo3 und Wordpress deshalb nur ungern in Frage, da der Code sehr schwerfällig und teilweise auch fehleranfällig geschrieben ist (und vor allem meist nicht objektorientiert und/oder php4-like). Meist gibt es aber keine funktional gleichwertigen Alternativen. Aber wie Titus schon sagte, die Codebasis interessiert den normalen Admin sowie die Benutzer nicht - mich früher eingeschlossen.

Im Übrigen macht es mit OOP viel mehr Spaß, sich den Code nochmal durchzusehen und evtl. Bremsen zu entfernen .

bei vB (und damals phpBB) suche ich mir das Template wo was machen soll, den Code in den PHP-Dateien der dafür zuständig ist, dann die nächstgelegene Hookstelle und frickel das ein was ich brauche (was ich auch zusammen bekomme, selbst wenn das ne Klasse oder Funktion ist)

Ja und? Im WCF geht das doch viel einfacher - da hast Du schon vordefinierte EventListener, die es auf jeder Seite gibt (show, readParameters,...). Dann nur noch das passende Attribut suchen, das manipuliert werden soll, package.xml sowie eventlistener.xml fertig machen und eine Datei mit den nötigen Anweisungen erstellen - wo ist das Problem ?( . Rückstandslos entfernen kannst Du es dann auch!

@Hawkes, geht mir genauso, der Code von der MFDB1.0 gefällt mir jetzt z.B. überhaupt nicht mehr und die MFCFB1.1 hätte man auch schon besser schreiben können. Wobei Du ja noch in einer anderen Code-Liga spielst .

Schade aber, dass die Qualität der Plugins in der WCom oftmals auch nicht so gut ist. Richtig schön finde ich den Code derzeit nur bei dem Portal 2.0 und dem Advertisement-System von GameR, wobei da die Kommentare im Englischen etwas brüchig sind. Das Wiki von Kawas ist z.B. leider fast gar nicht dokumentiert, andere haben ständig Mischmasch zwischen Deutsch und Englisch, sowohl in Kommentaren als auch in Parametern, Variablennamen, Methodennamen und Klassennamen oder holen sich die Kategorie-ID mittels intval($_GET['c']) und die Eintrags-ID mittels intval($_GET['id'])!! Das ist doch beim besten Willen kein WCF-Standard.. Um die MFCFB 2.0 möglichst nach WCF-Standards zu entwickeln, habe ich mir das gesamte Community Framework durchgesehen und bin noch begeisterter von dessen Programmierung :love: , auch wenn ich hier und da ein paar ganz wenige meiner Meinung nach Ungereimtheiten gefunden habe. Was mir aber nach wie vor nicht gefällt ist die Tatsache, dass ich für endanwendungsabhängige Optiontypes ein WCF-Paket anlegen muss, das diese Option dann hinzufügt - doch irgendwie nicht schön, denn ich hab ja dann in einem WCF-Paket MFCFB-Konstanten, die ja andere EAs theoretisch oder wie auch immer aufrufen können und dies dann mit einem Fehler quittiert wird. Schade auch, dass PiPs nicht wirklich EA-abhängig sein können. Wobei da auch wieder die Frage ist, wie das sonst funktioniert hätte...dann müsste man ja theoretisch den <files>-Tag in der package.xml ebenso vorziehen, damit das PIP im EA-Verzeichnis ausgeführt werden kann .

Nunja, aber um nochmal zum vB4 zurückzukommen, schade, dass der Code wirklich so schlecht und unflexibel ist. Seit dem WCF sind für mich Dateiänderungen gestorben 8) .

WCF rulez!

 

[Hawkes]

WCF rulez!

Dem habe ich nichts hinzuzufügen

Für Entwickler wie Anwender dürfte es mit dem vB4 aber richtig unschön werden. Dadurch, dass sie statt einem Rewrite des Codes nun während des vB 4 das ganze in Teilen nach und nach austauschen, wird es dann zwischen den einzelnen Versionen massive Updateprobleme geben und für Entwickler ist der Wartungsaufwand recht hoch.

Das Update WCF 1.0.x auf 1.1.x mit Plugins verläuft imho zwar auch holpriger als ich gedacht hätte, aber ich habe bisher 5 Plugins ans 1.1 angepasst, davon 2 neu geschrieben bzw. das Menü halt noch nicht fertig und bei den 3, die ich nur eben angepasst habe, waren das 5 - 10 Minuten Anpassungszeit an das WCF 1.1.x.

 

[rellek]

Nunja, aber um nochmal zum vB4 zurückzukommen, schade, dass der Code wirklich so schlecht und unflexibel ist.

Frage am Rande: Du hast den vB4-Code schon gesehen?


@ Weitsicht-Admin
Ähm... Einerseits wird die Software sooo weit vereinfacht, dass man gar nichts mehr wissen muss, außer, wie man einen Browser startet, und andererseits muss jeder Admin den Quellcode bis ins Detail verstehen? Da stimmt doch was nicht
Um die Code-Pflege kümmert sich doch der Hersteller der Software - beim Admin reichts doch, wenn er weiß wie er sie zu bedienen hat.

 

[Hawkes]

Ich wurde hier gefragt, wie der Code für die Q'n'D Lösung des obigen Problems lautet.

Es gibt im WBB 3.x keine vorgefertigte ACP Funktion dafür, aber in der WCom Plugins, um das zu erreichen oder man nimmt das includePHP Plugin von WoltLab und verwendet den Templateeditor im ACP.

 

[Titus]

@Hawkes
schon mal danke für deine Ausführungen, wirklich erleuten konnte mich das aber nicht, da sich mir das mit den Eventlistenern zwar erschließt ich aber noch nicht dahinter gekommen bin wann welcher aufgerufen wird

einen wirklichen Vorteil kann ich als Laie auch nicht ausmachen, für meine (vergleichen mit deiner) 1 Zeile Code (würde ich das wie du als eine Art Templatehook machen), brauchst du beim WCF schon mal etwa 4

Plugins bei vb sind ja auch keine Dateiänderungen, an den Quelldateien wird nichts geändert, daher sehe ich den Vorteil nicht wirklich, aber gut, da ich mich in die OO Programmierung nicht eingarbeitet habe, fehlt mir da wohl was um mich für das Zeug begeistern zu können

für mich sieht das alles einfach unnötig kompliziert aus

Im WCF geht das doch viel einfacher - da hast Du schon vordefinierte EventListener, die es auf jeder Seite gibt (show, readParameters,...). Dann nur noch das passende Attribut suchen, das manipuliert werden soll, package.xml sowie eventlistener.xml fertig machen und eine Datei mit den nötigen Anweisungen erstellen - wo ist das Problem . Rückstandslos entfernen kannst Du es dann auch!

hört sch gut an, nur wo finde ich die, das ist wohl mein primäres problem :whistling:

bisher hat man im Quellcode nachgesehen, jetzt ?(

Was mit vB4 wegfällt.

dachte das richtig dolle OO kommt nur bei den Teilen der Suite?
Das Forum sollte doch weitestgehend auf dem 3er Stand bleiben, sonst hätte man das Forum ja doch neu geschrieben was bisher ja nicht kommuniziert wurde und hier ja uA Gegenstand der Kritik ist 8|

großen, professionell konzeptioniertem Forum

das definiert sich wie genau ?(
die Foren mit >6 Mio Beiträgen sind wohl recht überschaubar, manch einer spricht bei über 500k schon von einem Bigboard, keine Ahnung was die "Profis" hier aufbieten können um sich professionell zu schmipfen :whistling:

 

[Hawkes]

bisher hat man im Quellcode nachgesehen, jetzt ?(

Jetzt denkt man einfach mal nach WoltLab benutzt mittlerweile so konsequent einheitliche Benennungen und Konzepte, dass ich oftmals mir nur kurz angucken muss, welcher Art dieser spezielle Teil der Software entspricht und dann schon klar ist, wie sie verschiedene Dinge gelöst haben, oder allein die Variablen bezeichnet.

Ja ich habe 4 Zeilen gebraucht du 1 und auf Dauer wirst du deutlich mehr Zeilen brauchen als ich. Sich mit den Eventlistenern auseinander zu setzen ist eine Art "Grundinvestition", die sich sehr ordentlich auszahlt.

Wie ich auch schon sagte: Das hier sind bereits Entwicklerthemen. Ein normaler Admin würde sich sowas niemals programmieren, sondern ein Plugin dafür installieren und von Entwicklerseite stehst du denke ich bei den meisten Entwicklern mit einem, eval($hook) sehr schlecht da.

 

[GameR]

Zumahl "eval" auf immer mehr Servern dicht gemacht wird... Zudem ist es leider auch langsamer als normaler PHP-Code.

 

[rellek]

Zumahl "eval" auf immer mehr Servern dicht gemacht wird...

Also DAS höre ich jetzt ehrlich gesagt zum ersten Mal. ?(

 

[Sebastian]

Das gäbe aber auch ein Problem im WCF1.1, da dort ebenfalls eval() verwendet wird.

 

[Titus]

OK ich huldige den Eventhandlern, wenn ich denn mal rausfinde welche es gibt und wo die liegen

ich denke was bei Servern/Webhosts bald mal Einzug halten darf ist ein PHP-Limit von weit mehr als 32MB, das ganze Paketgedöhns bringt einen echt zum verzweifeln
bei IPB3 steht die Empfehlung bei 128MB <- ja 128!
Zumindest beim Importieren der Sprache legt der Server auf jeden Fall mit "nur" 32MB den Löffel weg
Wege auf althergebrachte Weise per FTP einzelne Dateien hochzuladen sind leider dabei kaum vorgesehen, zumindest mit den Addons klappt (bzw ist garnicht anders vorgesehen) das bei IPB noch (wohl auch besser so, sonst würden die vermutlich 1GB Speicher für PHP brauchen )

 

[Hawkes]

Zumahl "eval" auf immer mehr Servern dicht gemacht wird... Zudem ist es leider auch langsamer als normaler PHP-Code.

Dann gibts aber mit dem WCF 1.1 und den dynamischen Sprachvariablen bald ordentliche Probleme oO

 

[GameR]

Ach, ihr müsst alle mal das Buch von Steffan Esser lesen. Eval ist BÖSE. :S

ehrlich gesagt, ich kenne bis jetzt auch eher Freehoster, die dsa dicht gemacht haben.

 

[rellek]

Ach Freehoster. Die verbieten auch die mail()-Funktion.

 

[rellek]

Große Ereignisse werfen ihre Schatten voraus:
Anhang anzeigen 62