Discussion in 'Plugins/Modules/Addons' started by willoriker, Apr 26, 2019.
Aah, unfortunately we are running multi server. But thanks for the information, that's good to know!
May I ask: Do we know how to deploy the APS Catalog as it was running, but on our community's' control?
May be we can collectively support the few more used apps (¡starting with wordpress!), it seems we are a few people running business around this feature, may be we can put some resources each of us on getting this functionality up and running
If there is interest for this, maybe it could work.
Also, maybe we could remove APS from the core and reintroduce it as a seperate module?
well, at least I do need to keep this functionality working, but as I never see how it worked before, don't know where to start.
¿do you have some hint?
I never developed a plugin for ISPConfig so I don't know if moving the APS installer from core to a separate module would be a lot of work (or not) or if it is a feature that can introduce new bugs. May be seeking to just provide the very same functionality in the near time and only then looking for moving it to a module would be better. I just don't know
On the other hand, having this code may be would be better, at least for the wordpress case, because it is working based con wp-cli which is a Wordpress' developed solution for CLI automation
Interesting thoughts, we would be interested in something like that. Actually, come to think of it.. Isn't the whole APS thing simply some XML files with definitions/configurations in the end? What if we would have that XML in ISPConfig, and make the WP version configurable for instance...
Extracting the whole thing from ISPConfig core sounds like a good idea to me.
If we do something like this, we should probably not try to create a super complete collection like APS did, but open it up for contributors so people can add/maintain the package that they specifically use. Otherwise having a dedicated team wouldnt even be enough to keep everything up to date.
I am also curious about branov's plugin. I'm not sure WP-CLI plays such a big role here - if it is only used for installation, I would consider it overkill. But if it allows more fine grained access to WordPress from within ISPConfig it would be cool.
I searched on my ISPConfig and found the file:
surely any can found it on each of our servers
It is not an XML or a script, it contains the files to install, sha256's checksums, scripts, etc.
I don't see this as viable as I thought a few hours ago.
Agreed; in my memory was aps_crawler.inc.php and aps_base.inc.php, which fetch data from apsstandard.org/1.2 . There is also http://apscatalog.com/1.2.atom which I thought was all we would need, but they package their own stuff. There's also some package inheritance, so a WordPress can have a language package for example.
Lets see what branov came up with. In the end, we only use Wordpress so if that works it could be good enough. Otherwise we may need to write our own module for it.
The actual problem is not if the aps installer is in core or if it's a module, if apps are available in aps format, we can simply leave it in the core. The reason for removing the installer is just that it does not make much sense to have an installer without having packages available. The problem is the availability of packages and who maintains them as I'm not able to maintain a bunch of packages beside of maintaining ISPConfig itself. The documents about the APS standard were available on the net in the past on the website apsstandard.org, but the company which runs apsstandard.org and apscatalog.com did not only remove the application catalog, they seem to have removed the documents about the whole package standard as well.
I'm also not sure if it would be possible to keep and maintain the old aps packages on your own server from a license and copyright standpoint. That the cms inside the package are open source does not necessarily mean that the package itself (config/scripts) are open source and may be maintained by someone else after the aps repo seems to have gone the closed source route.
In my opinion, the aps standard is overkill and too complicated from the view of a package builder and maintainer, just as @cpasqualini found out by looking at the packages, its in many cases a bunch of quite complicated scripts, config files etc. Also, the APS installer in ISPConfig is not implemented really well, it is a third party contribution that we bought from its original author at that time to make his code open source. If we want to form a group of users that maintains at least a base set of packages to be installed by a one-click installer in ISPConfig, then I would go another route:
1) Implement a new simplified app installer that uses a new repo at ispconfig.org and git.ispconfig.org where all users that are interested can contribute packages to. The repo basically consists of a MySQL database backend with easy to use admin UI for the authors where the package details like the package name, description, author, a screenshot, some details like if the cms requires a mysql db, admin password etc. and the maintainer are stored. The repository provides a REST API so that the ispconfig systems can connect to it to get package lists or fetch packages. this removes the need for parsing feeds etc. as the old system did.
2) Use a simplified package format. Basically a .zip file which contains:
- an install.sh or install.php file which contains the code to install the cms.
- a delete.sh or delete.php file with code to remove the cms
- a tar.gz or zip file with the actual code of the cms that shall be installed.
We might add a update sh/.php file as well, but I guess this might not even be necessary as it would make things much more complicated and mots cms provide online updates these days which handle the updates more easily.
Optionally and if we want to avoid having a separate GUI for the package maintainers, we can add a small XML file with the package details inside which would allow it to completely maintain the packages in git and the repository server at ispconfig.org would just import the packages incl. their details from the git system and just cache the package details in a MySQL database for the REST api.
The installer in ispconfig would then just do this:
- Download the package file and move it to the right place on the server.
- ISPConfig will provide an ini style file or PHP file in array syntax which contains the details for the installer script in the package like path where the cms shall be installed, database login details for the cms database if needed and optionally some passwords for the admin etc which can get read by the install.php/.sh file of the installer.
- Finally, the ISPConfig app installer executes the install.php or .sh file as website user and the package gets installed.
Regarding wordpress installation, you don't need wp-cli. Basically you just have to copy Wordpress to a folder and then the installer script sends a post request containing all required details to the URL of the wp install script. So WordPress is probably one of the easiest to install cms.
@till I think we can get with the scripts only, as most of the packages can be downloaded from their original upstream servers
so we need just to maintain a bunch of scripts (I do like the idea to use Git for this) with the (say) install, configure, update and delete actions.
The problem is that the scripts might need to be adjusted when a new version of a cms is out and it might be that the old file becomes unavailable, so in my opinion, it's safer to include the cms files into the installer package. Of course, having some scripts that build the packages automatically by downloading the cms source files incl. automatic tests of the new versions would be nice.
For info, 4 system know to Wordpress: https://wordpress.org/support/article/automated-installation/
APS, Fantastico, Installatron, and Softaculous
Installing WP automatically is probably one of the easiest CMS. As mentioned above, (as far as I know) the installer just needs to do a post request to the wp install script after copying the files. But WP will be definitely the test case that I use for building an example package.
@till Create a donate page with some options on your website
This seems interesting, I don't see a date when they posted this, but they are planning to share the code on GitHub... @till maybe you can contact them?
And maybe we should remove APS in 3.2?
Separate names with a comma.