How about multiple updater resource URLs?

[schulle4u]

Hello,

In Yellow it is already possible to configure update urls/files for themes and plugins. Now I'm wondering if the updater can handle multiple repository URLs to e.g. update 3rd-party plugins and themes from the command line or webinterface. As an example:

UpdatePluginsUrl: https://github.com/datenstrom/yellow-plugins, https://github.com/schulle4u/yellow-plugins-schulle4u

If this is possible, I could move my plugins into a centralized repository like the official one and users don't have to track each plugin repository for changes, even though they don't happen that often.

Steffen.

[markseuffert]

Hello Steffen,

it's a good idea. At the moment only the official plugins/themes use the software update, in the future all plugin/themes should be able to do that. I think the main question is how to make installation and maintenance of a website easier.

Here are my thoughts. The software update is not finalised yet, for example the file format will change. A single URL doesn't need configuration by the user, for example 3rd-party software can be listed there as well. I am not against multiple URLs, I am just thinking out loud what alternative would be good for developers and users.

Can we wait before releasing the update to all developers?

[markseuffert]

See also #187

[schulle4u]

You could put the update repository URL into each plugin's update.ini. Upon plugin installation the update URL, if not already exists, can be automatically appended to a list of URLs in system/config/config.ini- or even perhaps in a dedicated config file to avoid messing up the main configuration. However I'm wondering if this could have an impact on Yellow's performance when many plugins are installed, that's why I came up with the idea that every developer should be able to run a centralized repository for all his plugins instead of putting each plugin into it's own repo.

But there's no need to hurry up, this just popped up in my brain as an idea for possible future development. :)

Steffen

[wunderfeyd]

I'm undecided here... A URL for each plugin sounds nice since the developers are free to set up their own repositories which result in less interaction with the core development. BUT this is also a negative point. If the plugins aren't listed in a global super duper main repository and split up, one loses control and make the change/requirement tracing harder. For example an API change which would break some of the plugins could be undiscovered and result in unhappy users when the updated installation begins to fail.

While thinking about this, the real problem is to remember the plugin developers to update their plugins to a prerelease before the final release. At the moment there're not that many plugin developers but it might change over time and this could emerge to a real problem.

From the users perspective it's not important where the updates are downloaded from. It's essential the plugins work all together and the download source can be trusted (not injecting bad code).

[markseuffert]

In the meantime there's a new release plugin for developers.

It's an experimental feature and I added three of Steffen's plugins (audio, podcast, ticker). How does it work? If there's a new version for one of your plugins, you run the release command at the command line. This will update all necessary files. For example the version number in your own repository and in the official repository. Upload the changes to GitHub and send a pull request. As soon as the pull request is merged, the new version will be available via software update.

Steffen, please give it a try and let me know how it works.

[schulle4u]

OK, the release command seem to work properly for my own plugins, just tested in a debian subsystem under windows.

However I'm still a little confused by the workflow, so just to clarify:

1. I'm creating/updating my plugin as usual.
2. Create a release by running the release command for my own repository, e.g. php yellow.php release /mnt/e/Steffen/Documents/GitHub/yellow-plugin-xyz/
3. Execute php yellow.php release to update the official plugins repository as well?
4. Open a pull request to publish the new plugin version for software update?

The first release command only updates files in my own repository. If I execute the release command against my fork of the official plugins and theme repositories after creating my own release, the only thing that happens is that every plugin and theme in these repositories have their publication date updated in update.ini. Do I need to manually update version.ini and ressource.ini in order to have my plugins available for software update?

Steffen

[markseuffert]

Thank you for the detailed feedback.

I improved the release plugin to make it less complicated to use. Please adjust the new setting ReleaseSoftwareDir in file system/config/config.ini, it defines the directory containing your own repositories. Now you should be able to update all of your repositories with one command. The release command should automatically detect if one of your plugins has been changed. You don't need to manually update any files in the official plugins repository.

The workflow for a plugin looks like this, once everything is configured:

1. Create/update your plugin as usual, make sure to increase the version number in your code
2. Execute php yellow.php release, this will update both your repository and the official repository
3. Upload the changes and send a pull request, this will publish a new software release

[schulle4u]

Is it possible to use ReleaseSoftwareDir as a directory prefix for plugin release command?
For example if ReleaseSoftwareDir is set to /mnt/e/Steffen/Documents/GitHub/ I would like to just enter php yellow.php release yellow-plugin-example and the script uses ReleaseSoftwareDir as directory prefix. Currently I'm getting an error when trying this and would have to enter the whole directory path for individual plugin releases.
I'm asking for this because the release script currently works a little to perfect to be honest. :) Especially the release process in the official yellow-plugins directory is something I would like to keep under my own control. Currently the script even releases plugins which I don't want to have in this repository, e.g. example or test code. It would be great if each plugin optionally can be released individually without typing the full path.
But as said, the release process otherwise works perfectly.

[markseuffert]

Good idea, I added the feature to the release command. Thanks a lot for testing.

[schulle4u]

Thanks, but unfortunately it doesn't work. If I enter php yellow.php release yellow-plugin-example the script returns a success message, but no files are touched in my repository or in the official plugins repository. Only the absolute path works. Anything I can do to debug the output?

[markseuffert]

Found the bug, should be working with latest release plugin. Please try again, Steffen

[schulle4u]

Thanks, works perfectly now. Expect a pull request later this day. :)

[markseuffert]

Here's a summary of what's possible now:

• 3rd party plugins and themes can become part of the regular update mechanism
• plugin updates are stored in one repository, theme updates are stored in one repository
• website can be updated by the webmaster via web browser and command line
• website features can be installed via file system and command line
• website features can be uninstalled via file system and command line

Are you happy with this solution?

[schulle4u]

Thank you, this is a very good solution. A little like composer, but much cooler. :) Especially for new installations it is now possible to quickly set up all needed plugins/themes without manually downloading them from the repositories.

[markseuffert]

In the meantime the update mechanism has been simplified. Now all extensions are stored in individual repositories, there is no longer a differentiation between 3rd party extensions and official extensions. The software updater will download update settings for available extensions from the file system/extensions/update-available.ini in the main repository.