The Workflow Starts Automatically, with a Blog Updates Ping !?
I’m wondering if the Update Services of WordPress can work with the Webhook start feature of the cloud-based workflow?

In reporting website updates – one of the daily tasks, I think you can utilize a ping transmission as a trigger.

I think ideas are vital as an employee of Questetra who is always struggling to think of improvements in business processes. I can’t help recognizing that today in the API economy era XML-RPC is fairly obsolete technology, but I don’t care about that!

This is because if a new process is automatically started using WordPress updates as a trigger, the task of reporting website updates might be executed perfectly.

*The cloud-based workflow Questetra BPM Suite provides the Webhook start feature, and you can receive XML Webhooks as well as JSON Webhooks.
What is Update Services
Update Services < Post Settings (Writing) < Settings

Immediately, I tried to investigate.

Consequently, I succeeded in automatically starting up a new process.

However, two issues arose.

I’ve been using WordPress for about 6 years, and while I’d thought Ping was a relic of the past I was surprised that there was a mechanism that outputs two similar notifications (Ping and Extended Ping).

★The first result received in the workflow

<?xml version="1.0"?>
<methodCall>
<methodName>weblogUpdates.extendedPing</methodName>
<params>
<param><value><string>QUESTETRA BPM SUITE</string></value></param>
<param><value><string>https://questetra.com/</string></value></param>
<param><value><string>https://questetra.com/feed/</string></value></param>
</params></methodCall>

★The second result (same time)

<?xml version="1.0"?>
<methodCall>
<methodName>weblogUpdates.ping</methodName>
<params>
<param><value><string>QUESTETRA BPM SUITE</string></value></param>
<param><value><string>https://questetra.com/</string></value></param>
</params></methodCall>

From the viewpoint of automatically starting the workflow effectively, I’m not satisfied that there are two triggers.

However, if one of two triggers (e.g.”methodName = = extendedPing”) is modeled to flow to the automatic End Event using the Split Gateway, the Human Task of entering the updated contents of the website can be reliably generated.

Well, I want you to be aware that this ping is originally an update notification of Post-type articles so Page-type ones are not notified.

Sending a XML-RPC ping each time you create or update a “post”

My idea of perfectly implementing the task of reporting website updates was not realistic after all. In other words, only Post-type article updating is a trigger.

With that result, I decided to suspend my investigation.

At the same time, this idea was also dismissed, and from tomorrow I will keep trying to look for other ideas.

Incidentally, the multilingual plugin WPML my company uses only provides the information of English Post articles (recent posts) in the URL of https://questetra.com/feed/ , indicated in extendedPing (referring to the first result received in the workflow). That means that the extendedPing created by editing past Japanese articles is rather a useless notification.

Sobre o autor

Deixe uma resposta

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.

Rolar para cima
%d blogueiros gostam disto: