So I’m using the “other” embed tool to specify the injection URL.
I can see the request arrive at the webserver from the CMS when I add the embed to the page in the editor, and the server log reports a 200 response with the correct # of bytes for what I sent back to the CMS for inclusion into the page.
But the Ghost page editor reports “There was an error when parsing the URL.” and I see a request sent to the server from my remote browser:
GET /ghost/api/admin/oembed/?url=https%3A%2F%2Fexample.com%2Finject.pl&type=embed HTTP/1.1" 422 284
So my PERL script is sending the HTML code block to the CMS for inclusion (with no headers injected), but something is not quite right.
Any help gratefully accepted.
Note: Correct hostname replace by example.com as per recommended practice)
Gosh, I haven’t used Perl since 1996! Curious what framework are you using, or is it pre-framework days?
HTTP 422 errors can suggest that the data returned from the Perl site is malformed, maybe a syntax error or missing xml end tag, for example. I’ve seen it happen in Wordpress when database records became corrupt during an update, and since Ghost also uses MySQL, that’s a possibility.
Does this happen when you try different Perl pages from the Perl site? Just this one page? And did it work before and isn’t working now (and possibly you’ve done a Ghost update recently?)
All embeds work via the oEmbed spec. Your perl script will need to respond with JSON following that spec, likely using the “rich type” oembed format with your html in the html property.
Just be aware that it’s not dynamic, the embed html is only fetched one time when initially embedding. If you need dynamic data then you will need to use an iframe or some form of client-side script in your perl script’s response so that data can be fetched in the client when it’s displayed (many sites do it this way, like Twitter and YouTube).
No, all post content in Ghost is stored and cached as static HTML, if you need dynamically updating content inside a post it needs to be client-side or displayed via an iframe.
So a really powerfull feature that could be added would be a “code inject” option, where a URL is specified (rather than an embed object), Then the Ghost Developer could write the responding script in PERL, Python, PHP or whatever they’re comfortable in, and the returned HTML simply added to the page by Ghost as it’s sending the page HTML to the client.
Ghost isn’t set up to work like that, post content is static and not processed at all when rendering. Changing that would have huge knock-on ramifications for performance, caching, CDNs, etc.
What you want to do can be achieved with the tools available - client-side scripts or embedded iframes. If that doesn’t work for your use-case then you’ll likely need to look at either hosting those pages outside of Ghost or potentially going a different route with Ghost working as a headless data-source for a site built with your other use-cases in mind.
Wow, I’ve used this username for 3 decades online, and you are the FIRST person to ever correctly connect those dots!! You wouldn’t believe how many incorrectly dated birthday wishes I get! Mine was an '81 S, black, 5 speed manual, tan leather interior. I still have it!
Heh, My '88 S4 was same colours. That Tan is a bit horrendous. The car no longer exists - long but interesting story. '83 S was rubinrotmetallic inside and out - took a bit of getting used to but not too bad once you did.
Thanks for the info. Client-side does doesn’t cut the mustard AFAIK.
It took a bit of fiddling but I managed to crack it using old tech - Apache Server Side Includes. :^)
Hopefully soon I’ll have a blog page up with a demo.
One further question - Ghost blog pages all appear to be their own root directory, so the actual page has no suffix. Is it possible to tell Ghost to add the .html suffix to each page? At present Apache is having to process EVERY file coming through the proxy - being able to limit to .html would make things more efficient.