Custom action or parameters for the update API?

[froger-me]

I wanted to ask you a question. In the past I used this class to manage updates of themes and plugins, but I've never been able to find the efficient way to use it to create a page of add-ons available for a specific plugin.

The problem is that WP Update Server works at the level of a single plugin or theme. The instance of the UpdateChecker class is created by passing the server IP. the slug and little else. It can also be created by sending the path of a json file.

However the main problem is that the instance that searches for updates is always relative to a single package (theme or plugin). To create my add-ons page I modified the dispatcher (and all its properties) to read a new action called get_addons, with the slug parameter to be passed to the corresponding new methods.

In practice, a query args like this:

?action=get_addons&slug=theme-o-plugin-slug&version=theme-o-plugin-version

However, as a system it has become fragile and unmanageable when needs have grown and in addition to add-ons, patches and translations have taken over.

So what I wanted to ask you is this. How could one do to add this feature?

Quoted from https://github.com/froger-me/wp-plugin-update-server/issues/6

[froger-me]

Hi @adrix71,

You can definitely include custom parameters in the request, and extend the behavior with your own plugin plugging into the filter hooks wppus_update_server (to replace the WPPUS_Update_Server object with your own) and query_vars (to add your custom parameters such as get_addons). You can then inherit the proper update server classe and fill in the blanks to account for the behavior that suits you needs, or write your own code entirely.

[ghost]

Assumption: I take it for granted that we are talking about a plugin reserved for those who have self hosted themes and plugins not on wordpress.org, envato or other market and therefore must provide for everything.

It is absolutely correct what you say and it is what I did until recently; extending the class and personalizing it with my query vars.

It works, not deny this. The problem is that if the system grows as a number of themes, plugins, extensions, patches and i18n becomes extremely complex to manage and efficiency suddenly loses.

I think the problem is in the lack of database support. Your plugin uses a database table only for the management the licenses, and the original class uses only slug or json file.

Assuming that the wordpress plugin server, just to give an example, instead leans on a database (in the example plugins you have put a json files with references to things that must necessarily be extracted from the database - plugin rating and more) it is easier to manage all this and also use the extra Headers that help to identify the version or type of support needed.

Filter: extra_plugin_headers Filter: extra_theme_headers

For example, for a plugin it could correspond to something like this:

Dependency: My Plugin Dependency Version: 1.0.0

I am convinced it is possible managing manually but at the same time I think the best thing is to rely on the database. Just to do a test these days I wrote a plugin based on WP_List_Table that uses 3 classes to display as many forms to insert a theme and its dependencies which are then saved in the database using custom queries.

What I get query string like this:

?theme_name=my-theme&version=1.0.0

retrieved in a simple way by superglobal $ _REQUEST, the array containing references to the plugins that I have set as dependencies for this theme. Any other plugins stored in the database are not added to the dependencies list.

Passing this array to a version of TGM Plugin Activation that I modified and passing the values ​​to a plugin special admin page I get a graphical installer for plugins and managing any updates. The original WordPress plugin page remaining untouched.

Considering that the development of the TGM Plgun Activation class has been stopped from over 3 years (version 2.6.1 relased at May 19, 2016 and version 3.0.0 is lost in cyberspace) and that the last update back more than a year ago, so that the time to start the development an alternative system that allows developers have available something complete and easily manageable.

The question, time and personal and business commitments permitting, is if you want to try to expand your plugin together.

I wish you happy Sunday.

[froger-me]

Solution has been given for now: extend the plugin's classes for customization. Future updates will necessitate a database (most likely v2.xx) and a revamp of persistence will be done then.

Closing for now.