Drupal 8 Entwickler für "Parents for Future" gesucht

Hallo Holger,
da seid ihr jedenfalls in guter Gesellschaft.
Auch Greenpeace ist gerade dabei, vollkommen auf Drupal umzustellen.
Sie bezeichnen ihre neue Software als Greenwire.
Als Grundlage für dafür haben Sie die Distribution: openSocial von Drupal gewählt. Wie ich finde, keine so schlechte Wahl.
Ich habe noch nichts gefunden, was sich besser eignen würde, um ein großes Netzwerk abzubilden.
Ich habe schon ein bisschen damit herumexperimentiert.

Wollt ihr auch in diese Richtung gehen ?

Gruß
Berthold

Hallo Berthold,
ich antworte mal, da ich gemeinsam mit Holger bei Parents For Future an der neuen Seite arbeite.
Ja, wir verwenden OpenSocial und sind da bereits recht weit. Im Gegensatz zu Greenpeace läuft jedoch bei uns alles ehrenamtlich.

Derzeit sind 2 Themen ungelöst:
a) best practice: wie auf einem shared hosted server via composer von OS 4.10 auf 5.1 upgraden? (hier)
b) weshalb funktioniert das Liken nicht...? (hier)
Falls Du oder jemand anderes Lust hätte, hierbei oder grundsätzlich mitzuarbeiten, wäre das super!

@Liken
das funktioniert, ihr dürft nur nicht das Update vom 11. März fahren.
Schau mal hier.
Ich hatte auch erst das Update aufgespielt und dann ging es nicht mehr. Also wieder einen Schritt zurück und schon funktionieren die Herzchen wieder :-)

@upgraden von 4.10 auf 5.1
Ich denke nicht, dass ihr so vorgehen solltet.
Hängt euch nicht an die Distritbution dran. Ihr müsst jemanden haben, der das richtig gut beherrscht und der dann die Update für euch durchführt.

Wenn opensocial neue Features hinzugefügt hat, (ich habe das Update nicht gecheckt) würde ich versuchen, diese Features separat in die opensocial.

Wenn ich die Zeit hätte, würde ich das gerne für euch tun, ich habe schon versucht, hier in Aachen ansatzweise so etwas Ähnliches zu etablieren (Stichwort: nachhaltiges Aachen).
ich bin da aber auch noch nicht weitergekommen.

Gruß
Berthold

Hallo Berthold, danke, dass Du so schnell geantwortet hast.

Das kann ich leider nicht bestätigen. Ich habs mit mehreren Modul- und OS-Versionen getestet.

Dazu sage ich jetzt mal besser nichts...

@Liken
ich habe die Version: Like & Dislike 8.x-1.0-alpha2
INSTALLATIONSPROFIL Social (social-8.x-4.5)

und die funktioniert bei mir einwandfrei.

Die Version: 8.x-1.0-beta1 (2019-Mar-11)
funktionierte bei mir auch nicht.

@Dazu sage ich jetzt mal besser nichts...
Warum nicht...... vertrittst du eine andere Meinung ?

@Liken
okay, danke. alpha-2 läuft tatsächlich (unter OS v4.10).
Ich hatte alpha-3 mit verschiedenen OS-versionen getestet.

@Dazu sage ich jetzt mal besser nichts...
Warum nicht...... vertrittst du eine andere Meinung ?

Nein, selbstverständlich nicht. Nix für ungut, aber »Ihr müsst jemanden haben, der das richtig gut beherrscht« – klingt etwas überheblich...

Ich denke, wir haben genügend Erfahrung. Nur ist zwischenzeitlich immer so viel zu tun, dass es gut wäre, wenn man bestimmte Themen mal kurz jemanden übergeben könnte...

Oh, das sollte überhaupt nicht überheblich klingen.
Wieso klingt das eigentlich überheblich, wenn man sagt, »Ihr müsst jemanden haben, der das richtig gut beherrscht«. Das bedeutet doch nur, dass es schwierig ist und ich weiß genau, dass es schwierig ist.

Naja, ist auch egal....

Was ich sagen wollte ist nur (Antwort auf deine Frage a), daß es sicherlich kein gangbarer Weg ist, OpenSocial nach der veröffentlichten Distribution zu aktualisieren, also auf diese Weise die Softwareupdates durchzuführen.
Da wird man sehr viele Probleme mit den schon eingegebenen "eigenen Daten" bekommen.
Außerdem wollt ihr das System ja bestimmt "aufbohren", in der 4.1 ist z.B. noch kein Kalender integriert, wenn ich mich nicht täusche. Vielleicht ist der ja bei der 5.1 ja dabei, das habe ich nicht getestet.

Ich bin mir sicher, dass ihr schon wisst, was ihr tut, wie ich gesehen habe, beschäftigst du dich mit Drupal ja auch schon seit einigen Jahren.

Composer-Update auf Shared Hosting kann klappen, muss aber nicht.
Wo hosted Ihr denn?
Bei 1&1 unlimited pro keine Chance. Da reicht einfach das PHP Memory Limit der Version, die auf der Konsole läuft nicht aus uns nach Selbstaussage des Supports wird sich daran auch so schnell nichts ändern.
Da hilft dann nur lokal oder sonstwo updaten, wo es läuft und wieder hoch schieben.
Bei All-Inkl hatte ich bislang keine Probleme, da funktioniert das Composer Update einwandfrei (wenn man sich dann mal durchgesucht hat, wie es grundsätzlich funktioniert ;-))

@torfnase: Alles Gut!
»Aufbohren« in dem Sinne, dass ich dort selbst bereits ein paar Funktionen neu hinzugenommen habe – na klar. Aber ich arbeite auch mit anderen Distributionen, mit denen trotz meiner Ergänzungen die Composer-Updates klappen.

Derzeit liegt diese Installation bei Artfiles.de (professional WebCloud-Server). Mit denen bin ich seit 16 Jahren äußerst zufrieden. Und andere Skripte via Composer zu updaten bereitet dort auch keine Probleme.

Mit OpenSocial klappten die Updates über mehrere Versionen ebenfalls problemlos. Nur der Versionssprung von 4.10 auf 5 eben nicht. V5.1 enthält mehrere zusätzliche Libraries, ist auf VBO angewiesen und beinhaltet Modulpatches und läuft z.B. auch nicht mit Pathauto 1.4

Mit Herumschrauben an composer.json habe ich dann in Rücksprache mit dem OS-Team das Update bereits einmal hinbekommen. Allerdings mit einem Haufen Errors, weshalb ich wieder zurückgegangen bin. Mein Verdacht ist, dass in Version 5 etwas zu sehr mit heißer Nadel gestrickt wurde.

Und da das Skript ja läuft und Content und User hat und ich sowieso über die Ohren damit zu tun habe, die Community voranzubringen, hatte ich es erst mal hinten angestellt. Nur leider beinhaltet Version 5.1 vieles, was ich auch gerne hätte.....

Mich von der OS-Entwicklung abzukoppeln behagt mir ehrlich gesagt (noch) nicht.....

Klingt gut, das muss ich unbedingt mal testen.

Da bleibt Dir nichts anderes übrig, als mal die Issues zu betätigen, bzw. die Beobachtungen, Fehler zu melden, damit Du differenzieren kannst: Was ist Composer-Problem wegen shared Hosting und was ist Problem der Version 5.

Sonst bleibt das einfach ein Stochern im Trüben womit man keine Produktivseite betreiben kann.

Und die Programmierer sind ja auch drauf angewiesen, dass sie feedback bekommen.

Ich habe die Open Social 5.1 auch mal installiert. Das ist echt ne geile Software :-)

Läuft auf den ersten Blick recht rund. Pathauto 1.3 oder Pathauto 1.4 funktionieren beide problemlos.
Liken funktioniert aber nur mit der Version: 8.x-1.0-alpha2, wie gehabt.
(ich habe es nur lokal auf meinem WAMP installiert).

Ein Kalender scheint immer noch nicht integriert zu sein, ist aber ja nicht so schlimm, kann man auch selbst machen.

Habe das Update jetzt auch hinbekommen.
Und wie Du sagst, es läuft rund, bis auf...:

Hast Du mal in der 5.1er-Version ein Childtheme erstellt?
Und falls ja: erscheinen bei Dir in den Themesettings die neuen Einstellmöglichkeiten z.B. zum Gradientfaktor bei den Heroimages?

nee, ich habe noch kein "richtiges" Childtheme erstellt....

Ich habe mal aus dem social-Blue ein social-Green theme gemacht (also zusätzlich, nicht social_blue ersetzt), also alles umbenannt, das war ganz unproblematisch und alles wird richtig angezeigt.
Da kann man dann natürlich alles individuell einstellen, und es wird nicht überschrieben, heißt ja dann social_green und nicht mehr social_blue.

Ich bin kein Designer und habe auch kein Gefühl für Formen und Farben. Ich finde auch das mitgelieferte Theme ganz toll.

Mittlerweile läuft alles ganz prima. Das system lief bisher unter OD5.5 und G8.7.4 stabil
Es sind ca. 200 Gruppen gemeldet und bald 1000 user.
Soweit so gut.

Nur plötzlich produziert der Aufruf der Mitglieder-managements der Gruppen, der über eine View bereitgestellt ist, einen unexpected error: »TypeError: Argument 1 passed to Drupal\block\BlockViewBuilder::view() must implement interface Drupal\Core\Entity\EntityInterface, null given, called in ...../DIR/html/profiles/contrib/social/modules/social_features/social_group/social_group.module on line 1102 in Drupal\block\BlockViewBuilder->view() (Zeile 30 in ...../DIR/html/core/modules/block/src/BlockViewBuilder.php) ....«

Die View selbst ist definitiv okay und ich bin mir nicht bewusst, dass ich am System etwas verändert habe.
Wenn ich eine Neuinstallation erstelle und per Backup-Migrate die db in das neu erstellte und identische System neu aufspiele kehrt der Fehler wieder.
Habt Ihr eine Idee, wie dem weiter auf den Grund gehen kann?

Erhält ein Block in der View keine Ergebnisse, wo bisher welche waren?
Nur geraten...irgendwas muss sich ja geändert haben.

Diese View ist per default durch die Distro vorhanden, stellt allerdings gar keinen Block sondern eine Page bereit.
Ich habe spaßeshalber einmal diese View gelöscht und per Konfigurationssynchronisation durch diese View einer bestehenden funktionierenden Seite ersetzt.
Es erscheint wieder derselbe error.
Für mich ein echtes Rätsel.

Problem gelöst. Falls jemand das im detail interessiert – bitte melden.

Klar interessiert das. Ich denke auch über ein Open Social Projekt nach.
Muss nicht ausführlich sein, aber ein paar Stichpunkte wären schon toll.

Kurz gesagt fehlt in der OpenSocial-Readme folgender Hinweis:

Wenn man ein Childtheme erstellt, indem man das vorgegebene socialblue-theme dupliziert und entsprechend umbenennt, MUSS derzeit das ursprüngliche socialblue-Theme in der Appearance aktiviert bleiben. Falls Du es deaktivierst, weil Du denkst, Du brauchst das ursprüngliche Theme ja nicht mehr, arbeitet die View, welche die Membership der Gruppen darstellt, nicht mehr und es wird der error produziert.

Einem anderen User war zum selben Zeitpunkt wie mir exakt das Gleiche passiert und er hat das hier inkl. Lösungsvorschlag sehr dezidiert beschrieben.

Zum Glück gab es jemanden aus der ForFuture-Bewegung, der mir da weiterhelfen konnte.