Proposal: Introducing a composer-plugin for OIDplus projects.

[wehowski]

Goal(s):

• Composer Plugin:
  Install OIDplus Plugins by just $ composer require vendor/example-oidplus-plugin into the correct path.
• Other tasks (e.g. installer-/update scripts...)...?

Example/Test
To get an basic example we take the plugin wich is very small and unfinished yet, already living in (registry.frdl.de):
plugins/frdl/adminPages/io4
To git: https://github.com/frdl/oidplus-io4-bridge-plugin
The only addition to get the thing work for this plugin is to add 2 entries to a composer.json (type and extra.installer-name):

{
    "name": "frdl/oidplus-io4-bridge-plugin",
    "type": "oiplus-plugin-admin-pages",
    "description": "Bridge from OIDplus to Webfat/IO4",
    "keywords": ["oiplus", "io4"],
    "license":  ["MIT"],
    "autoload" : {
        "classmap" : ["OIDplusPagePublicIO4.class.php"]
    },
    "extra" : {
        "installer-name" : "io4"
    }
}

We install it into the test-instance https://test-ra.weid.info/ with a composer.json file as published here: https://test-ra.weid.info/composer-json.php

Result: The git repository of the plugin lives in the root directory of the package but is installed to the correct OIDplus plugin-path by composer: plugins/frdl/adminPages/io4

Long story short:

• https://getcomposer.org/doc/articles/custom-installers.md
• https://github.com/oomphinc/composer-installers-extender

[wehowski]

• Ggf. können noch einige der ganzen path-definitionen aus dem root composer.json entfernt werden, da sie vom composer-plugin ge-merged werden...
  Muss getestet werden (entsprechen z.B. der autoloader-settings und der initial packages/classes...

[wehowski]

Ich habe mal roave/security-advisories hinzugefügt und es hat eine Warnung für firebase/php-jwt ausgegeben, deshalb habe ich in der Testinstanz firebase/php-jwt >=6 aktualisiert!

[wehowski]

@danielmarschall Du könntest probieren, ob Du das ganze schlanker hinbekommst, z.B, ausgehend von https://github.com/oomphinc/composer-installers-extender
Das sind im wesentlichen die OIDplus Pfade:

 "installer-paths": {
			"vendor/{$vendor}/{$name}/":             [
				"type:library",
				"type:project"
			],
			              
			"plugins/{$vendor}/publicPages/{$name}/":              [
				"type:oiplus-plugin-public-pages"
			],
			"plugins/{$vendor}/raPages/{$name}/": [
				"type:oiplus-plugin-ra-pages"
			],
			"plugins/{$vendor}/adminPages/{$name}/":             [
				"type:oiplus-plugin-admin-pages"
			],
			"plugins/{$vendor}/auth/{$name}/": [
				"type:oiplus-plugin-auth"
			],
			"plugins/{$vendor}/database/{$name}/": [
				"type:oiplus-plugin-database"
			],
			"plugins/{$vendor}/sqlSlang/{$name}/": [
				"type:oiplus-plugin-sql-slang"
			],
			"plugins/{$vendor}/logger/{$name}/": [
				"type:oiplus-plugin-logger"
			],
			"plugins/{$vendor}/objectTypes/{$name}/": [
				"type:oiplus-plugin-object-types"
			],
			"plugins/{$vendor}/language/{$name}/": [
				"type:oiplus-plugin-language"
			],
			"plugins/{$vendor}/design/{$name}/": [
				"type:oiplus-plugin-design"
			],
			"plugins/{$vendor}/captcha/{$name}/": [
				"type:oiplus-plugin-captcha"
			]
		}

[danielmarschall]

Hm... I am not sure.
You know, I am not a friend of composer at all (except for development).

I rather thought about a WebGUI that let the user choose, install and uninstall from the control panel. Like an app store. Wordpress has something like that.

I have two real-word-examples where I cannot access composer.

1. I have a server at STRATO where I have PHP, MySQL und FTP. I don't have access to the shell. So composer is useless?
2. I have a IIS Webserver running on Windows. How to use composer with this? (Remember, people might not have access to the Windows Desktop, so they might not be able to run the command line or install software!)

[wehowski]

No problem.
As the suggested solution works by only adding one composer.json file, someone could

• use this optionaly as there is nothing to change on the existing plugins
• this makes only sense in development context

One use case would be that plugins can require plugins and solve the dublicate class files problem.

However, I close this issue.

---

1. • 2. composer läuft z.b. auch als .PHAR(?). Setting 2. habe ich nur einmal kurz getestet, da habe ich keine Erfahrung.

WebGUI 👍 should be there for endusers (can be wrapped around commands/api/cli...)

[danielmarschall]

If you think that composer as phar can be called on a shared web hosting, maybe your composer plugin can be wrapped with a WebGUI. So why do you close the ticket?

[wehowski]

sorry, I reopen the issue.
Composer can be used definitly on shared hosting, yes (if .PHAR or exec or something is available.
I tested it successfully before, by file_get_contents the phar "manually" and execute the composer scripts.
Also some classes of composer can be used independently.
But also yes, it is important to seperate the install dev from production/enduser.

Finally, as at this point there are only two significant entries in the composer.json a WebGUI can parse it and copy the plugins into the correct dirs manually without composer.

...die Möglichkeiten sind vielfältig... ich plädiere in der Regel dafür die Installers/Setups vom App-System zu separieren.