textpattern
Investigate an alternative for XML-RPC
There are numerous outstanding issues/TODOs relating to Textpattern's XML-RPC interface, including: https://github.com/textpattern/textpattern/issues/874, https://github.com/textpattern/textpattern/issues/1012, https://github.com/textpattern/textpattern/issues/1050, https://github.com/textpattern/textpattern/issues/1051 and https://github.com/textpattern/textpattern/issues/1052.
@philwareham mentioned GraphQL as a replacement/successor to XML-RPC, and @Bloke is also in favour.
I propose we officially deprecate or end-of-life XML-RPC for 4.7.0, and set the tone that it will be replaced by GraphQL or similar in an upcoming version. I can't see any need for considerable code changes, but a note about its deprecation should be included in HISTORY.txt and perhaps the code inline.
If this is acceptable, I'll close the other meta/[inline TODO] issues relating to XML-RPC and we can move forward.
@bloatware and @makss -- are you happy with deprecating XML-RPC and GraphQL being its successor?
We can’t deprecate without a replacement bring in place. So it won’t be until at least 4.8. Drawback of GraphQL is that the officially recommended PHP implementation requires PHP 5.5. Although there is probably no technical reason why something couldn’t be achieved with 5.3 I guess.
Actually, yes - if you put it like that, there is no replacement right now. I stand corrected - thanks, @philwareham.
I'll close this and shut off the XML-RPC issues, with code comment updates to point to the respective issues for completeness.
Reopened and added a tentative 4.8 milestone to this. The issue is a valid one so shouldn't be closed really. However, we should close all other XML-RPC related issues since this is obsolete tech and not really worth fixing IMO.
Something for consideration: Micropub, currently W3C Recommendation –
https://www.w3.org/TR/micropub/ https://micropub.net/draft/
Do editors the likes of MarsEdit support Micropub? There's no official notice I can find on their website but there is mention that it does (CollectedNotes seems an interesting project, btw). EDIT: This list of Micropub clients may well be out of date but support seems pretty good for third party tools.
I know XML-RPC is old code and I don't see the need to update it (short of a massive security hole being discovered) but dropping support if there are people comfortable editing their site content from third party tools doesn't feel right.
Supporting more modern standards: definitely. Micropub seems as good as any. GraphQL, whatever. Maybe both, who knows? Whichever gives most bang for the tiniest footprint and has the most predicted longevity.
EDIT2: iA Writer just announced Micropub support so if we can fold Micropub in somehow, Destry'll be pleased :)
I know XML-RPC is old code and I don't see the need to update it (short of a massive security hole being discovered) but dropping support if there are people comfortable editing their site content from third party tools doesn't feel right.
That's fair. You're right. It's effectively obsolete but it's not exactly burdensome to maintain. Zero open issues at the moment.
Supporting more modern standards: definitely.
This is my area of interest, hence the mention of Micropub - though it seems I've drifted a bit since the OP was opened.
Also, this is a good read: https://www.manton.org/2020/04/20/api-history-detour.html
Micro.blog has always worked with MarsEdit, but because it’s based on a standard that was frozen, MarsEdit could not support all of Micro.blog’s features. And while Micropub is clearly the future, there is more we could do now without requiring MarsEdit to be adapted for Micropub.
Nice.
I've just been doing some reading too. Trying to find a simple Micropub PHP library we could just include and then wrap to support 3rd party content injection into Txp. Not found anything small enough yet. Most are behemoth systems or require (parts of) bloaty frameworks like Laravel.
During my travels however, I fell upon IndieAuth which is a federated login protocol to permit people to log in to services using their own domain as an authorisation endpoint. Like when you go to a service and see 'Login with Facebook' or 'Login with Google' you can 'Login with my own site'.
Seems all we'd need to do is include something tiny like selfauth. Setup is as simple as uploading that (optional) dir from our bundle - just like you do with /rpc - and visiting (say) example.org/auth. You see a page asking for an endpoint and a password.
A good endpoint might be example.org/authors/{your-txp-login} because then multiple authors could authorise/publish to the same site. Not sure how good that selfauth file is at multi-author config setting (I suspect it's geared up for single users). If that's the case we might be able to do something a bit neater by rolling it into the Admin->Users panel. Maybe if you click an 'Authorise' button and provide your regular Txp password, it could associate the relevant API keys with your author. Not sure, but that seems safer than having setup open to the world.
Once a password has been configured, you can add the required header to your site <head> via a tag (just like the old <txp:rsd /> I guess). That enables authorisation from third-party apps via your Txp site; one per author.
Does that help us? Dunno. But that might open the gates to tools that support IndieAuth (there are a few). They could use our API to inject stuff into Txp. All we then need to do is decide what we expose and write stubs for them. iA Writer, Micro.blog, any Micropub clients in theory. We'd just need to find (or build) the parts of the Micropub spec that made sense.
Further, does authorising to our own domains/sites potentially make it simpler for obtaining things like Twitter feeds and Facebook post streams? Who knows. I've only started reading about it today. But since it's built on OAuth2, without all the headaches of the flawed OpenID debacle, it seems a nice entry point to allow us and plugins to explore ways to integrate with other services.
If I've misunderstood any of this, please feel free to realign my thinking. Early days.
@Bloke - pretty much in agreement with you on all the above, though we're straying a bit from the OP issue…which I'm coming round to thinking is probably best closed within the bounds of deprecating something in order to replace it with something else.
Reminder that we should probably remove rsd when XML-RPC disappears.
https://docs.textpattern.com/tags/rsd
For info, according to https://php.watch/versions/8.0/xmlrpc the PHP XML-RPC extension is being migrated to PECL from PHP 8.0.
@petecooper as far as I know, we don't actually use any of the xmlrpc functions from that extension. I'm still keen to get rid of XML-RPC in favour of a modern API though.
For example: using the micropub standard to accept incoming content, using GraphQL to transmit outgoing content.