Structure of custom transport provider

[Baugis]

Hi everyone,

We’re trying to set up our own transport provider so we can easily download and install our in-house packages across different MODX sites. However, we’re struggling to make our endpoint a valid transport provider.

When adding the provider in MODX, we get this error:

This Provider could not be verified, and therefore cannot be used as a MODX Provider. Please check the service URL and try again.

What we’re missing is a clear understanding of how the provider endpoint should be structured – specifically what the index.php or XML response needs to look like in order for MODX to recognize and interact with it properly.

Has anyone here created a custom transport provider before and could share some guidance on the required structure or a working example?

Thanks in advance!

[halftrainedharry]

@Baugis

When adding the provider in MODX, we get this error:

I took a quick glance at the MODX source code:

When you add a new provider in the MODX manager, the code makes a GET request (to the “Service URL*” you entered) to verify the user.

For example:

• You enter “Service URL*” = https://mydomain.com/
• The code makes a request to https://mydomain.com/verify and adds various request parameters:

http://modx312.com/verify?api_key=...&username=...&uuid=...&database=mysql&revolution_version=Revolution-3.1.2-pl&supports=Revolution-3.1.2-pl&http_host=...&php_version=8.1.0&language=en

As a response it expects an XML like this:

<?xml version="1.0" encoding="UTF-8"?>
<status>
  <verified>true</verified>
</status>

[jako]

This simple package provider code is maybe be a good start: GitHub - huksley/modx-package-provider: Sample implementation of MODx Package Provider