man könnte so etwas sicherlich zunächst auf Module beschränken. Allerdings ist – wie Florian bereits erwähnt hat – die Personaldecke bei WBCE leider recht dünn. Das soll aber keineswegs heißen, dass die Entwicklung ins Stocken geraten ist. Ich bin nun schon lange bei WBCE dabei, und sowohl früher als auch heute ist das Team stets engagiert, hilfsbereit und bemüht, Lösungen anzubieten.

Eine Möglichkeit wäre also, das Ganze zunächst auf Module zu begrenzen. Dafür müsste der Aufbau eines Moduls so gestaltet sein, dass eine Layout-Datei verwendet wird, die hauptsächlich aus anpassbaren Variablen besteht. Allerdings ist es bei Updates meist unvermeidlich, dass auch diese Layout-Dateien manuell angepasst werden müssen – insbesondere dann, wenn sich der zugrunde liegende Code in der Standardauslieferung ändert. Eine vollständig automatische Berücksichtigung solcher Anpassungen bei Updates wird es vermutlich nie geben, es sei denn, das gesamte System wird grundlegend umgestellt. Natürlich kann ich mich dabei auch irren. Wenn jedoch alles über eine entsprechende Datenbankstruktur abgebildet wird, könnte so etwas grundsätzlich möglich sein.

Ich selbst arbeite daher mit zwei Systemen: einer Live-Seite, die stabil und produktiv läuft, und einer OTE-Seite (Testumgebung). Dort prüfe ich Updates im Vorfeld ausführlich. Das ist zwar mit mehr Aufwand verbunden, zahlt sich aber aus, da man Änderungen vorab testen kann. Auch ich habe einige Standardmodule angepasst, die bei Updates wieder auf den Originalzustand zurückgesetzt werden – was ganz normal ist.

Daher mein Tipp: Arbeitet am besten immer mit zwei Umgebungen – einer Live- und einer Testumgebung (OTE).

Leider ist es ein altbekanntes Problem. Es verschicken viele über das Kontaktformular leider viel Spamnachrichten, obwohl Spamschutz drinne ist.
Diese Leute nutzen leider auch viele Proxy und VPN Server.

Währe es möglich dass man schaut, dass es ein Modul gibt, das mit https://proxycheck.io/ zusammen arbeitet?

Lieben Gruß
Cronka

Dann wird wohl nur eine manuelle Lösung übrig bleiben.

Danke für die ausführliche Stellungnahme!

danke für die schnelle Antwort. Ich war leider einige Zeit außer Gefecht und komme jetzt erst wieder dazu weiterzumachen.

Hast du eine Idee wie man eine automatische Anmeldung für einen User realisieren könnte.
Ich würde das auch in Form eines Freelancer Auftrag abwickeln.

MFG
Roman

Dann kann ich morgen mal damit anfangen, das ganze optisch an das Layout anzupassen. Und das Wort MENU muss noch wech.
Aber ggf. mal suchen, ob ich das Menu-ICON nicht eh durch das Bootstrap-ICON ersetzen kann.   

Wenn ich heute ein Projekt wie ein CMS anfangen würde, würde ich definitiv auf Symfony aufsetzen. Alternativ auch auf ein anderes, möglicherweise kleineres Framework, aber Symfony ist schon geil, trotz der Hürden. Das Composer-/Kommandozeilen-Rumgefrickel ist auch der Tatsache geschuldet, dass es mittlerweile eben kein Monolith mehr ist, sondern aus sehr vielen optionalen Komponenten besteht. Die Lernkurve ist schon enorm, vor allem für mein altes Hirn, aber es lohnt sich durchaus.

Auf der anderen Seite muss man trotzdem vieles bedenken. Der WBCE-Core ist extrem schlank. Wenn ich mir meine lokale Portable angucke, ist die mit Inhalten unter ./media und zusätzlichen Modulen so etwa 90 MB groß. Ein noch relativ leeres Symfony-Projekt hingegen umfaßt schon jetzt rund 170 MB, ohne dass da schon viel an eigenem Code oder gar Assets drin wären. Das vendor-Verzeichnis umfaßt unterhalb des Namespace "symfony" schon jetzt satte 71 Verzeichnisse. Kann viel und ich brauche es für dieses Projekt halt auch, aber für WBCE wäre das eine Menge Ballast. Allein Doctrine als Datenbank Engine vs. class.database.php in WBCE entspricht einem Elefanten vs. einer Mücke. Klar kann Doctrine mehr - aber die DB-Klasse in WBCE kann alles, was notwendig ist.

Der Aufwand, WBCE mit Symfony neu zu schreiben, ist nicht zu stemmen. Allein die Einarbeitung braucht extrem viel Zeit. WBCE läßt sich zur Not leicht patchen, weil es leicht zu durchschauen ist. Das macht es für eine breite Fläche von Anwendern und Modulentwicklern attraktiv, die nicht jahrelang PHP "studieren" wollen. Für alles andere gäbe es genug andere Projekte auf dem Markt, wie Typo3, ProcessWire oder Drupal. Wer gar nicht mit Code in Berührung kommen will, bekommt bei den Providern auch einfach zu bedienende Klicki-klacki-Lösungen oder geht zu Jimdo und Co. WBCE hat seine Zielgruppe, und für die funktioniert es einwandfrei.

Der Wunsch, auf einem Framework aufzusetzen, ist absolut nachvollziehbar, aber man muss hier auch Aufwand und Nutzen gegenüber stellen. Wenn das Ziel ist "es ist hinterher wieder WBCE, nur halt mit Framework drunter", ist das Aufwand-Nutzen-Verhältnis indiskutabel. Zumal die Beteiligten ja auch jede Menge Zeit investieren müßten, die die meisten nicht haben. Und das auch noch für lau.

Was man natürlich machen kann: Symfony-Komponenten, die gut isoliert funktionieren (wie Twig), als Modul zur Verfügung stellen, so dass andere Module sie verwenden können. Aber auch das lohnt nur für extrem umfangreiche / komplexe Module oder halt für sowas wie Twig.

Siehe auch
https://forum.wbce.org/viewtopic.php?pid=42958#p42958

Beitrag #6

Nachtrag:
Wenn bereits PHP 8.x im Einsatz ist, musst du das berücksichtigen:

https://forum.wbce.org/viewtopic.php?pid=39014#p39014

vielen Dank für eure ausführlichen Informationen, so ähnlich hab ich das befürchtet.   Werde mal das Anzeigenscript ausprobieren.

Schönes WE weiterhin
nasowas

hast Du mit dem Code rumexperimentiert?
Wenn es dazu fragen gibt, lass mich wissen.

Damit kannst Du zwar nicht jeder Sektion/Abschnitt (SectionID) eigenes HTML geben aber jedem Modul-Typ. Und zusätzlich kannst Du auch die section-ID mit ins Layout schreiben, den Modul-Typ und gerne auch "sectionname".

Auch anderweitig, falls es Fragen/Feedback gibt, immer her damit.

Christian

• Triggern kann man das ja mit dem onclick Event auf ein Element einer bestimmten Klasse

• diese Klasse könnte man vielleicht der letzten Spalte zuweisen, so dass man gar nicht mehr aktiv was hinterlegen muss, auf das man dann klicken kann

• Die Zeile würde man aus dem DOM bekommen (hoffe ich) und die Tabellenzellen in einem Array vorfinden, oder sonstwie über Children iterieren, um die Zellen zu bekommen

• Datumsangaben muss man entsprechend dem ics Standard umformatieren

• Auch bei Sonderzeichen (z.B. Umlaute, und ß im Straßennamen bei Ortsangaben) muss man aufpassen, wie man die maskieren muss, um einen gültigen ics Eintrag zu generieren (wobei gefühlt jedes Programm seinen eigenen Standard setzt)

• Auch Zeilenumbrüche in längeren Beschreibungstexten sollte man glaub ich einfügen...

Das ICS Format ist in RFC 2445 beschrieben

Jepp. Bei zb Templates wär es gut, wenn man kleine Werte in die Datenbank speichern kann, etwa die Farben oder wieviele Spalten usw.
Und bei vielen kleinen Modulen.
Idealerweise mit einem mehr oder weniger automatischen Input/Dialog-Generator.

Ich hab mal angefangen mit sowas, bin aber nicht recht weit gekommen; mein PHP-KnowHow ist eben überschaubar.
DB-mäßig war das einfach eine Tabelle mit "Zweck" (nach einem Schema) und einem Feld Text für ein Array.

Sichere das Adminverzeichnis mit htaccess, dann hast 2 Faktoren ;-)

Ja das ist auch eine Möglichkeit aber nicht unbedingt das was ich meinte ;-)