@"Mogens Fiebrandt"#232 ich hab den Entwickler der Extension schon mal angeschrieben er macht im Bereich TYPO3 nix mehr und wird sie auch nicht mehr Weiterentwickeln so stand es zumindest im Mail das ich von Ihm bekommen habe. Ich verwende die Extension nur für ein Projekt und wüsste auch keine bessere dafür, deswegen hab ich da auch ne menge Zeit investiert und werde versuchen die auch noch eine Zeitlang am Leben zu halten weil ich die brauche. Ich bin kein Programmierer und deswegen will ich die nicht Forken oder Übernehmen weil ich keine Ahnung davon habe, für die Zwecke wo ich sie brauche reicht es für mich aus. Wenn sich ein Programmierer findet der sie weiter betreiben will kann er gerne meinen aktuellen Code haben ich hab kein Problem damit und auch sicher der Ursprungsentwickler Frans Saris auch nicht nehme ich mal an... Wenn jemand die Ext. braucht kann er die natürlich auch von mir haben schreibt mir eine Nachricht und ich sende sie Euch funktioniert für v12 - v13 für v11 gibt es ja den diesen [Downloadlink](https://packagist.org/packages/minifranske/fs-media-gallery)

@"The_C"#p2967 Ich habe eben realisiert, dass ich die Extension `fs_media_gallery` selbst zurzeit in unserer Vereins-Website im Einsatz habe. Den Bedarf für eine v12 kompatible Version der Extension hätte ich also schonmal. Da das mit der Sortierung der Gallerien immer nicht so gut funktioniert hatte bzw. schwer zu kontrollieren war, wollte ich die zu gegebener Zeit ersetzen. Nach der Diskussion hier überlege ich aber, ob ich der Extension im Zuge des eigenen v12 Upgrades vielleicht doch noch eine Chance gebe. Kannst du mir evtl. mal eure aktualisierte Fassung zukommen lassen? Wenn die Veröffentlichung eurer Arbeit an dieser Extension für euch ok ist und du das selbst nicht machen möchtest/kannst, könnte ich das zumindest mal als Fork einstellen. Wenn ich dann irgendwann mal Zeit für die nächste ehrenamtliche Tätigkeit finde, kann ich mich dann auch selbst mal etwas in den Code einarbeiten und evtl. etwas beisteuern.

@"Eric Harrer"#8 klar kannst den Code haben!

Super, danke dir fürs Teilen des Projekt-Codes (privates Repository). Ich sehe es mir zu gegebener Zeit mal genauer an. Ich denke aber es macht Sinn die Extension zu gegebener Zeit vereinzelt in einem öffentlichen GitHub Repository bereitzustellen, um künftig darin besser gemeinsam arbeiten zu können und auch anderen Interessenten/Nutzern/Entwicklern die Gelegenheit zu geben den Code einzusehen und über Pull Requests beizutragen. Über einen [VCS-Eintrag](https://getcomposer.org/doc/05-repositories.md#loading-a-package-from-a-vcs-repository) in der `composer.json` deines Projektes könntest du dann das Repository mit einbinden und die Extension im aktuellesten Stand weiterhin ganz normal per `composer install` installieren.

@"The_C"#p2967 Schön zu sehen, dass mit ein wenig reden über die Dinge so schnell jemand gefunden ist, der auch die Extension benötigt. Vielleicht hast Du ja mit Eric auch schon einen Projekt-Lead gefunden für die Extension, wenn Frans Saris die nicht mehr haben möchte. Ich hab leider keine Ahnung, wie man eine Extension übernehmen kann. Aber vielleicht weiss das ja jemand anders hier im Forum oder sonst sicher jemand im TYPO3 Slack Channel. Ein guter Weg ist ja auf jeden Fall erstmal einen Fork zu haben, den man über Composer sauber installieren kann. Nur so bekommt man ja auch andere dazu die Extension auch zu nutzen. Und vielleicht findet sie ja auch den Weg zurück ins TER und nach packagist. So geht Open-Source 😊

Ich könnte ja am Wochenende mal schauen, ob ich die Version mal durch Rector durch jage, um zu sehen, ob ihr alles für TYPO3 12 habt. Dafür würde sich ein offener Fork natürlich super eignen. 😉 Das wäre ja prinzipiell schnell erledigt.

Wie ginge den das wenn ich auf GH die Ext frei zur verfügung stelle ginge das jetzt aus meiner Testseite die auch schon auf GH liegt oder muss ich da ein eigenen GH zugang machen und das irgendwie mir ddev aufsetzen hab das noch nie gemacht... Wär echt mal interessant zu wissen wie das geht

Was meint ihr: bisher liegt die Extension bei Bitbucket. Ein echter Fork mit Bezug zum ursprünglichen Repository und der Möglichkeit daraus dann einen Pull Request abzuleiten wäre nur bei Bitbucket gegeben. Auch wenn ich selbst ebenfalls lieber mit GitHub arbeit wäre das ggfls. Ein Grund bei Bitbucket zu bleiben statt ein neues Repository bei GitHub anzulegen als lose Kopie ohne Bezug. Wie seht ihr das? Oder gibt es Cross-Plattform-Kooperationsmöglichkeiten von denen ich bisher noch nichts weiß?

Das hat schon mal wer sowas gemacht: [https://github.com/web-vision/fs_media_gallery](https://github.com/web-vision/fs_media_gallery) Ich würde GitHub nehmen.

@"Eric Harrer"#p2983 Die Übergabe der lese und/oder TER Schreibrechte sollte möglich sein im TER Login Bereich des Maintainers unter "Managing my access tokens". Hier kann ein Token für die Extension erzeugt werden, der an den neuen Maintainer übergeben werden kann.

@"The_C"#p2984 man kann ja beliebig viele Forks eines Repositories erzeugen. Die Tatsache dass schonmal jemand geforkt hat wäre kein Argument gegen Bitbucket. Wenn du GitHub lieber magst können wir auch erstmal dort kooperieren. Falls es tatsächlich spruchreif wäre, den Maintainer abzulösen können wir die Frage ja nochmal neu diskutieren und ggfls. den entwicklungsstand auf Bitbucket hochladen um einen PR erzeugen zu können. @"Mogens Fiebrandt"#232 wie würdest du diese Frage einschätzen?

Weiterentwicklung der EXT:fs_media_gallery

Mogens Fiebrandt

Super. Vielen Dank @Eric Harrer.

Ich habe gestern jetzt:

einen Fork der Extension bei Bitbucket geholt. (Das war echt ätzend, weil ich irgendwie 2 Accounts bei Bitbucket habe. Und keinen davon vorher benutzt habe. Irgendwie haben die Probleme, wenn man dann SSH Keys verwenden will. Total nervig. Jetzt eben per HTTPS.)
die Extension in einer TYPO3 12er Umgebung in der Version 4.x aufgesetzt.
Erste Änderungen an der Extension gemacht. Aber eher Aufräumarbeiten. (@Eric Harrer Du hast einen Pull-Request für den 4.x Branch in Deinem Repo)
Einen Slack Channel erstellt (#ext-fs-media-gallery) für die Kommunikation bei der Entwicklung. Der ist öffentlich. Also wer gerne wissen will was da so abgeht, kann gerne dazu stoßen. Den Thread hier können wir dann ja nutzen, um den Fortschritt zu posten, aber müllen den dann nicht so zu mit Entwicklungsabsprachen.

@Steffen Sehr gerne. Feedback ist immer erwünscht. Die Extension läuft unter TYPO3 12. Zumindest die im Branch 4.x. Am besten über Composer aufsetzen. Geht aber natürlich auch im Legacy-Mode. Ist meiner Meinung nach aber komplizierter, wenn man den aktuellen Entwicklungsstand pullen will. Wenn Du dabei Hilfe brauchen solltest, kannst Du ja gerne im Slack-Channel nachfragen.

Ein Issue-Tracker wäre noch ganz nett. Bei Bitbucket läuft das irgendwie über JIRA. Müsste man sich mal mit befassen, wie man das realisieren kann.

Bei der Entwicklung für v13 würde ich gerne einen Gang zurück schalten und die Extension erstmal unter v12 aufräumen und danach mit einem sauberen Stand auf die v13 gehen. Zumindest sollten wir zunächst die Plugins und Flexforms aufräumen und ordentlich zum Laufen bringen. In den Flexforms sind z.Bsp. noch Switchable-Controller-Actions drin hab ich gesehen. Die gibt es in v12 garnicht mehr. Die Plugin Einstellungen funktionieren damit garnicht.
Jetzt habe ich mir die Extension gestern aber auch zum ersten mal angesehen und aufgesetzt. Ich hab noch garnicht richtig verstanden wozu die 5 Plugins alle benötigt werden.

Eric Harrer

Mogens Fiebrandt Das Problem mit mehrfachen Accounts bei Bitbucket hatte ich auch. Folgende Anleitung half hier weiter:
https://support.atlassian.com/bitbucket-cloud/docs/managing-multiple-bitbucket-user-ssh-keys-on-one-device/

Im Grunde musst du nur jeweils einen eigenen Host in deiner SSH config Datei definieren, der auf das jeweilige IdentityFile zeigt.

#account 1
Host bitbucket.org-acc1
  HostName bitbucket.org
  User git
  IdentityFile ~/.ssh/id_rsa_acc1
  IdentitiesOnly yes

#account 2
Host bitbucket.org-acc2
  HostName bitbucket.org
  User git
  IdentityFile ~/.ssh/id_rsa_acc2
  IdentitiesOnly yes

Den Host kannst du dann in der Adresse des Remotes setzen.

# für Account 1
git clone git@bitbucket.org-acc1:erhaweb/fs_media_gallery.git
# für Account 2
git clone git@bitbucket.org-acc2:erhaweb/fs_media_gallery.git

bzw. nachträglich im bestehenden Repository:

# für Account 1
git remote set-url origin git@bitbucket.org-acc1:erhaweb/fs_media_gallery.git
# für Account 2
git remote set-url origin git@bitbucket.org-acc2:erhaweb/fs_media_gallery.git

The_C

@Mogens Fiebrandt die 5 Plugins sind verschiedenen Modi ich selber hab immer nur in der Nested List gearbeitet und ehrlich gesagt die anderen noch nie ausprobiert, aber kann man ja mal probieren was da rauskommt...

Mogens Fiebrandt

Eric Harrer Danke für den Tip. Allerdings wollte ich jetzt nicht noch einen weiteren SSH Key anlegen. Da ich ja beide Accounts vorher schon gar nicht benutzt habe. Also auch keine Repos dadrin waren.
Ich konnte es jetzt lösen.
Das Problem war, dass ich meinen 2. Account gelöscht habe. Allerdings hatte ich vergessen vorher den SSH Key dadrin zu löschen. Da der Account aber noch 14 Tage reaktiviert werden kann, kann man den SSH Key dann nicht in einem anderen Account hinzufügen. Also musste ich den Account reaktivieren und erstmal den Key dort löschen - Danach den Account wieder löschen.
Danach habe ich den SSH Key zu dem Repo in dem aktiven Account hinzugefügt. Danach konnte ich dann zwar pullen, aber nicht ins Repo pushen. Folgende Fehlermeldung:

Unauthorized
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Das fand ich ziemlich weird.
Letztendlich habe ich dann herausgefunden, dass man seinen SSH Key an 3 stellen hinterlegen kann:

1) Im Repo selbst. Dadurch hat man aber nur Read-Access.
2) Im Workspace. Auch hier hat man dann nur Read-Access.
3) In den pers. Einstellungen. Nur wenn man den Key dort hinterlegt, hat man R/W-Access und kann auch pushen.

Ob das jetzt so sinnvoll ist, weiss ich nicht. Aber irgendwas wird sich Bitbucket schon dabei gedacht haben. Oder auch nicht. 🤣

Eric Harrer

Mogens Fiebrandt Achso, dann hatte ich deinen Fall Missverstanden. Naja Bittbucket ist sicherlich auch nicht die erste Plattform meiner Wahl aber hier müssen wir erstmal nehmen was wir kriegen bis zum Wechsel auf eine andere Plattform als offizieller Maintainer.

Dein PR sieht soweit beim Überfliegen solide aus, kann man das schonmal mergen oder magst du ihn erstmal für weitere Commits nutzen?

The_C

Da ich auch noch keine bis wenig Erfahrung mit Bitbucket habe wäre es auch sicher interessant für alle zu erfahren wie man sich das jetzt schlußendlich von dort installiert.
Ich versuche es mal und wenn es falsch ist bitte korrigiert mich:

In der composer.json erstellt man einen Bezug zu REPO

"repositories": {
	"fs-media-gallery": {
		"type": "vcs",
		"url": "https://bitbucket.org/erhaweb/fs_media_gallery/"
	},
},

Über Composer installiert man jetzt das REPO von Bitbucket
ddev composer require minifranske/fs-media-gallery:4.x
FERTIG die fs-media-gallery ist bereit zum Einsatz.

Eric Harrer

The_C richtig, so geht es.

Allerdings bevorzuge ich diese Array-Schreibweise für Inhalte von "repositories" ohne den unnötigen Key für die darin befindlichen Einträge:

"repositories": [
	{
		"type": "vcs",
		"url": "https://bitbucket.org/erhaweb/fs_media_gallery/"
	}
],

Also der Composer Dokumentation nach (noch ungetestet) müsste für die TYPO3 v12 kompatible Version bzw. den 4.x Branch unseres Forks eine der folgenden Schreibweisen für die Installation verwendet werden:

# Direkte Referenz auf den letzten Stand des Branches 4.x
ddev composer require minifranske/fs-media-gallery:dev-4.x

# Nutzung des branch-alias der composer.json der Extension
ddev composer require minifranske/fs-media-gallery:4.0.x-dev

# Die zuletzt getaggte Version könnte man so installieren
ddev composer require minifranske/fs-media-gallery:^4.0

Für den Moment würde ich aber den ersten oder zweiten Weg empfehlen, da so sicher immer der neueste Stand verwendet wird. Ich habe seit Upload des Stands von @The_C bisher noch kein neues Tag angelegt.

@The_C hatte den die Installation mit der von dir genannten Zeile auch funktioniert?

The_C

Eric Harrer ja hat so funktioniert ddev composer require minifranske/fs-media-gallery:4.x
Zuerst dacht ich mann muss die URL vom Repo in der composer.json einsetzen "url": "https://bitbucket.org/erhaweb/fs_media_gallery/src/4.x/" das erwies sich dann als falsch den der Composer schrieb eine Fehlermeldung raus:

❯ ddev composer require minifranske/fs-media-gallery:4.0.x-dev
In Hg.php line 97:                                                                                                                                             
Failed to clone https://bitbucket.org/erhaweb/fs_media_gallery/src/4.x/, hg was not found, check that it is installed and in your PATH env.                                                                                                                                               
sh: 1: hg: not found

Deswegen dacht ich mir das ein kleines Install Tutorial nicht falsch ist weil so oft macht man das ja auch nicht.

Steffen

Hej Folks,
ich bin jetzt so weit, dass ich das Upgrade meiner TYPO3 Instanz von v11.5 auf v12.4 vorbereiten kann und wollte mal testweise die Extension minifranske/fs-media-gallery installieren. Nur komme ich hier in meiner lokalen Umgebung nicht weiter. :/

Das Repro soll idealerweise mit TYPO3 v12.5.x, Apache und PHP8.2 laufen.

In die composer.json habe Folgendes geschrieben:
"repositories": { – und noch zwei eigene Repros – "fs-media-gallery": { "type": "vcs", "url": "https://bitbucket.org/erhaweb/fs_media_gallery/" } }

Das Ganze habe ich dann versucht zu installieren mit ddev composer require minifranske/fs-media-gallery:dev-4.x bzw. ddev composer require minifranske/fs-media-gallery:4.0.x-dev. Beides klappt nicht. :/
Was mach ich da falsch? Hat jemand einen Tipp für mich?

Besten Dank
Steffen

Mogens Fiebrandt

Versuch mal:

ddev composer require minifranske/fs-media-gallery:4.x

Eric Harrer

Hiermit funktioniert es (getestet):

# entweder
ddev composer req minifranske/fs-media-gallery:4.x-dev
# oder
ddev composer req minifranske/fs-media-gallery:@dev

Der Branch heißt 4.x, der letzte Entwicklungs-Stand dieses Branches wird dann per 4.x-dev geholt.

Evtl. wäre es leichter nachzuvollziehen gewesen, wenn der Branch 4.0.x genannt worden wäre, dann hätte man per 4.0.x-dev installieren können.

Aktuell haben wir außerdem noch folgendenb Branch Alias definiert:

"branch-alias": {
    "dev-master": "4.0.x-dev"
},

Ich glaube das müssen wir in dem Branch entweder ganz entfernen oder umbenennen zu:

"branch-alias": {
  "4.x-dev": "4.0.x-dev"
},

da ja nun Branch master nun die v13 kompatible Version führt.

Steffen

Moin zusammen,
vielen Dank Mogens und Eric für eure Hilfe.
Ich habe Eric's erste Option für die Installation verwendet, die hat geklappt. Vielen Dank

Mein Setting in meiner DDEV Umgebung:

Apache
PHP8.1. und PHP8.2
TYPO3 v12.4.17

Fehler treten bei mir keine auf. 👍
Vielen Dank euch allen, Steffen

Eric Harrer

Steffen Ok, super, das bedeutet ja dann, dass auch der Upgrade Wizard, den ich am 13. Juni noch ergänzt hatte, auch bei dir funktioniert hat.

Dieser kümmert sich darum, die veralteten "SwitchableControllerActions" in dedizierte Plugin Content Elemente zu überführen.

Steffen

Hej Eric, meinst du damit, das angelegte Alben in die entsprechend neuen CE's konvertiert werden?
Das hat leider nicht geklappt.

Eric Harrer

Steffen So, wie es in der Meldung im Screenshot auch steht.

Das bisherige Plugin mit list_type = fsmediagallery_mediagallery wird migriert in die jeweils dedizierten Plugins:

"Nested List" → fsmediagallery_nestedlist
"Flat List" → fsmediagallery_flatlist
"Show Album By Config" → fsmediagallery_showalbumbyconfig
"Show Album" → fsmediagallery_showalbum
"Random media asset" → fsmediagallery_randomasset

Hast du den Upgrade Wizard denn mit dem DB-Stand der ehemaligen EXT:fs_media_gallery aus v11 ausgeführt?

Bei meiner Vereinswebsite funktionierte das einwandfrei. Wenn es bei dir nicht funktioniert wäre es cool, sich mal den DB-Stand vor der Migration ansehen zu können, um der Ursache auf die Spur zu kommen.

Sebastian Müller

Eric Harrer

Hi zusammen, vielen Dank für Eure Arbeit an der Extension!
Ich habe Sie installiert und das meiste hat sofort funktioniert.
Ich hatte ein Problem das potentiell mehrere haben könnten und wusste nicht wohin damit.

Durch die Aufteilung des Plugins in einzelne Plugins klappt unter Umständen die Einzelansicht nicht mehr.
In der Partials/MediaAssets/Thumb.html wird ein Link mit <f:link.action und action="showAsset" gebaut.
Ich verwende das Plugin "ShowAlbumByConfig", bei mir hat TYPO3 aber immer Links zum Plugin "NestedList" gebaut.

Grund: Wenn kein pluginName angegeben ist, schaut TYPO3 (uriBuilder) nach dem ersten Plugin für diese Controller/Action-Kombination

Lösung: im <:link.action noch das Plugin mitgeben <f:link.action pluginName="ShowAlbumByConfig" ....

Mögliche Probleme: Wenn man verschiedene Plugins verwendet, muss man aufpassen, da mehrere Partials/MediaAssets/Thumb.html verwenden und dann pluginName nicht pauschal gesetzt werden kann sondern z.B. beim Partial-Aufruf mitgegeben werden müsste

Steffen

Vielleicht ist das ein Verständigungsproblem auf meiner Seite ;)

Ich habe gestern das Upgrade auf v12 ohne EXT:fs_media_gallery ausgeführt. Heute habe ich dann die EXT:fs_media_gallery hinzugefügt und war zuerst auf der Seite wo das CE eingesetzt wird. Das war zu diesem Zeitpunkt nicht konvertiert. Dann habe ich den WIzard ausgeführt; das "alte" Galerie CE war auch danach nicht konvertiert.
Die neuen Listenelemente des CE's sind verfüg- und einsetzbar.

Ich nehme an, dass du mit dem WIzard eine Konvertierung des alten Listenelement in eins der neuen machen soll. Richtig?

Eric Harrer

Steffen die beschriebene Vorgehensweise ist so in Ordnung. Das Upgrade kann auch nachträglich durchgeführt werden, wenn sonst nichts am Zustand der betroffenen Plugin-Contentelemente verändert wurde.

Konkret wenn

CType den Wert list hat
list_type den Wert fsmediagallery_mediagallery
und im FlexForm eine ehemals verfügbare switchableControllerAction
konfiguriert ist (oben benannt)

dann greift der Upgrade Wizard.

Könntest du dahingehend mal prüfen, ob diese Bedingungen vor Ausführung des Wizards vorlagen? Der Wizard selbst zeigt dir auch an, wieviele zu migrierende Elemente in der DB vorliegen.

Exportiere mir bitte mal einen tt_content record, der nicht migriert wurde, dann kann ich prüfen was da los ist. Ich vermute, dass irgendetwas im FlexForm nicht richtig erkannt wird.

Steffen

Eric Harrer Moin Eric, na klar gerne.
Den Datensatz, der nicht migriert wurde, schicke ich dir über Slack. Den kann ich hier nicht uploaden.
Dann habe ich grade mal den
Upgrade WIzard aufgerufen, da kann ich den von dir nicht sehen. Sollte der nicht irgendwas mit media/gallery finden…? 🤔
Mache ich da was falsch?

Vielen lieben Dank fürs Helfen und des Supporten der Extension.
Steffen

Eric Harrer

Steffen Danke dir für das Feedback. Ich konnte das Problem nun finden und korrigieren.

Ich hatte einfach vergessen, die QueryBuilder Restrictions (also Berücksichtigung der Felder hidden, starttime, endtime, etc.), die standardmäßig greifen, zu entfernen. In deinem Fall war das Content-Element versteckt (hidden=1).

Künftig werden wirklich alle Datensätze berücksichtigt, die nicht als gelöscht markiert wurden (deleted=1).

Du müsstest also nun das Package aktualisieren:

composer update minifranske/fs-media-gallery

und anschließend den Wizard ausführen

typo3 upgrade:run fsMediaGallery_migratePlugins

Falls in der Konsole dann folgende Meldung angezeigt wird:

! [NOTE] Wizard fsMediaGallery_migratePlugins already marked as done

müsstest du vor der Ausführung des Upgrade Wizards in PhpMyAdmin folgenden SQL-Befehl ausführen

DELETE FROM `sys_registry` WHERE `entry_key` = "MiniFranske\\FsMediaGallery\\Updates\\MigratePlugins";

Falls keine zu migrierenden Elemente gefunden wurden, wird folgendes in der Konsole ausgegeben:

! [NOTE] Wizard fsMediaGallery_migratePlugins does not need to make changes. Marking wizard as done.

Falls etwas gefunden wurde, und die Migration erfolgreich war wird folgendes ausgegeben:

[OK] Successfully ran wizard EXT:fs_media_gallery: Migrate plugins

Falls du DDEV benutzt, musst du in den o.g. Konsolenbefehlen natürlich noch ddev voran stellen.

« Vorherige Seite Nächste Seite »

Unterstütze das Forum

Hilf mit, den Community Hub für TYPO3 werbefrei zu halten und die Betriebskosten zu decken. Werde Official Community Hub Supporter für nur 5 Euro im Monat (zzgl. USt) und erhalte ein exklusives Supporter-Badge. Jeder Beitrag zählt!

Jetzt Supporter werden

Impressum - Datenschutz - Kontakt - Netiquette - RSS