Well, there both is - and isn't an API. I have this habit of choosing names that indicate what a software does. Like my EU e-Privacy Directive plugin - it was designed to help you comply with the EU e-Privacy Directive. Kind of taking the mystery out of plugin selection. Need a plugin that enhances Meta Robots - I happen to have a plugin to do that, it's named Meta Robots. It's a sort of theme, or maybe a character flaw.
Content - Indexing API was named after the Google Web Content Indexing API service (you can see the theme, surely). So it's not specifically designed to be an API - but it does have an interface for you to call. It's very small, and calling it is super easy, barely an inconvenience.
I have a much longer article with a very specific and detailed example of how to interface with Content - Indexing API, so I won't get too detailed on the minutia in this article. I'm going to skip right to the point. Surely there's a developer out there who doesn't care about my example implementation or want to read that whole article to get to the 3 lines of code he wants to see. So, here they are:
$dispatcher = $this->app->getDispatcher();
PluginHelper::importPlugin('content','indexingapi',true, $dispatcher);
$dispatcher->dispatch('onContentAfterSave', AbstractEvent::create('onContentAfterSave',$contentEventArguments));
Let's get the bolded items out of the way first, because I made them stand out so I could get them out of the way.
Those are absolutely required. Don't alter them for your event, or it won't work. You've been warned.
I Lied (Sort of)
Now, these aren't the only 3 lines of code you need. These are the pieces that actually transfer data to my plugin, and initiate the API calls to Google and Bing - but there are other pieces necessary to make this work. Let's start with AbstractEvent because it requires the least brainpower to process.
Somewhere at the top of your script lives a list of "use" statements. Add this one:
use Joomla\CMS\Event\AbstractEvent;
Sweet, now that's out of the way - let's tackle the actual data you're passing to the plugin in $contentEventArguments
$contentEventArguments
$contentEventArguments = [
'context' => 'IndexingAPIExternalTrigger',
'subject' => $data,
'isNew' => false
];
Again, the bolded items are necessary to the proper function of the interface, leave them as is. $data, on the other hand, is going to require your attention.
Surely you'll notice that "context" is not a traditional Joomla style com_component.viewname context - DUH! I wanted to listen for a context that would never EVER happen in the wild. The plugin listens to a specific list of supported (naturally occurring) contexts AND this one.
$data
$data = (object)[
'link' => 'index.php?option=com_whatever&view=default&yadda&yadda&yadda'
];
It doesn't require much attention, it's an array cast as an object (or you could create an object directly, though it actually takes longer to process and takes more code). Simply populate the link key with your UNROUTED url, and the plugin will take care of the rest, calling Route::_() on your link and passing it to the search engines.
Is there a reason to NOT pass an unrouted URL? I've considered adding an additional 'route' property which defaults to true for those cases where you don't want the URL to be passed through Route::_(). I can do it, is it necessary? Let me know if you would find that useful.
This is Written Backwards
Yes, well, that's the way it is. The "API" in a page....probably less than a page, depending on your font size.
