Textpattern CMS support forum
Hi Jukka, Now that you made your time travel I remember about the discussion. Unfortunately then, the code returned an error when used in a txp site.
The database error issues you mentioned shouldn’t have any relation to the code, while the old code doesn’t work (but not because of that). If the errors appeared during saving (via admin-side interface), then the cause assumable might be, for instance, bad escaping in SQL queries ran by the used editor. If you were trying to save the code as a rah_extenal_output’s snippet and used outdated release (pre-v0.4), then the problem would be the editor and SQL statement escaping (which was fixed in v0.4 update).
When I use it in an independent php page now, the txp content is not fetched and it shows the alternative html instead.
If you are trying to use the old code posted back then, it should not work (as it is). Yes, you did read the not correctly. Unlike not-so-popular believe, my just examples, not tested, probably won’t work clauses are true statements and I cowardly stand behind them. The snippet I posted back then has some typos, fatty fingers so to speak.
The newer code I posted today, on the other hand, is functional and works just fine (it’s even tested – rare).
As compatibility goes, it does require up-to-date version of cURL (as in PHP5), privileges to make outbound HTTP (port 80) connections. Also you would want to change the example URL in the snippet (as full URL, string, nothing extra) and make sure that there are no re-directions or incorrect HTTP status codes sent by the target server.
Last edited by Gocom (2012-02-10 15:49:05)
If anybody wants to use this plugin to create simple XML that is then parsed by something like smd_xml (like I was), I’ve written up my experience.
Thanks to SOCOM for releasing this killer plugin.
Rah_external_output v1.0 is now available. The update includes number of changes. The main thing everyone updating will see is that there is no extra panel anywhere. Now the plugin uses Form partials to operate. Creating new snippets happens from Forms panel, and these snippets are stored as standard forms. All tools that are specific to forms on database level or present on the Forms panel, like the Tag Builder, now work with rah_external_output. Guys that are used to cnk_versioning may like that.
New features include user-configurable HTTP header lines and file extensions. A snippet using .xml extension will now be served as XML document. Lines at the beginning of the snippet staring with a semicolon are sent as headers.
This release is Textpattern 4.5.0 compatible. Older version, including v0.9, do not work with TXP v4.5.0 (or newer).
Full list of changes:
- Removed: Plugin’s own user interface. The plugin now uses
rah_eo_prefixed form partials and integrates with Forms panel.
<txp:rah_external_output />tag. As forms are used, normal and more flexible output_form tag can be used.
- Removed: Raw PHP support to comply with r3706.
- Added: Ability to set a snippet’s content-type using a file extension in the name.
- Added: Migration assistant script. The script is run automatically on install and migrates rah_external_output snippets from the old interface to Forms.
rah_external_output.snippet_endcallback event for developers.
- Changed: Returns a 404 page instead of the home page when requesting a nonexistent snippet.
- Changed: Tag trace can no longer be controlled using a URL parameter. A tag trace is added when the snippet name has a
.htmlextension and the site is in debugging mode.
- Now requires PHP5 or newer.
- Compatibility with Textpattern v4.5.0.
Last edited by Gocom (2012-07-14 02:15:24)
I’m using the plugin and this snippet to provide content across sites.
Can you advice on how that can be replaced using the new version of the plugin?
Can you advice on how that can be replaced using the new version of the plugin?
The plugin behavior is the same, and old snippets are migrated to Forms during install too. All old snippets will be kept intact and URLs stay the same too. In other words, you shouldn’t have to change anything.
Excellent, so elegant. Had me fooled after I upgraded to this latest version until I rtfm and found my XML document renamed and tucked away midst the forms. As an aside, because I don’t know if it’s a v1.0 issue only, I can’t preview the output, an ATOM feed, in any of the browsers I have on my iPad, Safari, Chrome and Dolphin. Error messages say ‘Can’t handle or can’t download this file’. Not a big issue.
Excellent, so elegant.
As an aside, because I don’t know if it’s a v1.0 issue only, I can’t preview the output, an ATOM feed, in any of the browsers I have on my iPad, Safari, Chrome and Dolphin. Error messages say ‘Can’t handle or can’t download this file’. Not a big issue.
Could be a browser thing even. Is the generated Atom file working even when browsers report so? Can you share the code you are using to generate the Atom feed or a link to it? If it’s private and can not be shared, what content-type are you using? It could be either be a unrecognized content-type (by browser), contradicting headers or slightly invalid markup. XML documents are strict about validity.
If I’m not mistaking Safari’s current development version on desktop Mac OS (ML) drops feed support. When accessing a Atom/RSS feed you should be redirected to an application of your choosing. If no feed handler is set, you get nothing.
iOS and Mobile Safari (which is the only browser engine used under the hood on iOS including iPhone and iPad) do not open Atom or RSS feeds at all. iOS uses Apple’s servers to fetch, syndicate, process and convert feeds to HTML pages. If this Atom feed is local or not publicly accessible (e.g. password protected), you will get an error.
Hello Again Jukka, Just to be clear, the feed works as intended on desktop (Mac) versions of Safari, Chrome et al. I wouldn’t have know about the iOS issue if I hadn’t been idly laying in bed this morning playing with my iPad. You can see the output in it’s pre-Feedburner state here. The code is:
; Content-type: text/xml <?xml version="1.0" encoding="utf-8"?> <feed xmlns="http://www.w3.org/2005/Atom"> <title><txp:site_name/></title> <subtitle><txp:site_slogan /></subtitle> <link href="<txp:site_url/>?rah_external_output=SAFEX-docs" rel="self" /> <link href="<txp:site_url/>" /> <id>http://iexpe.org/?rah_external_output=SAFEX-docs</id> <updated>2012-07-08T17:21:23Z</updated> <txp:file_download_list category="safex-newsletters" limit="1" sort="created desc" break=""> <entry> <title><txp:file_download_name title="1"/></title> <link href= "<txp:permlink id='234'/>" /> <id><txp:site_url/>file_#_<txp:file_download_id/></id> <updated><txp:file_download_modified format="%FT%TZ" /></updated> <summary><txp:file_download_description /></summary> <author> <name><txp:file_download_author /></name> <email>firstname.lastname@example.org</email> </author> </entry> </txp:file_download_list> <txp:file_download_list category="safex-incident-notices" limit="9" sort="created desc" break=""> <entry> <title><txp:file_download_name title="1"/></title> <link href= "<txp:permlink id='237'/>" /> <id><txp:site_url/>file_#_<txp:file_download_id/></id> <updated><txp:file_download_modified format="%FT%TZ" /></updated> <summary><txp:file_download_description /></summary> <author> <name><txp:file_download_author /></name> <email>email@example.com</email> </author> </entry> </txp:file_download_list> </feed>
The generated links for each file item in the download list are intentionally identical so that they lead the site user to a password protected page where he or she can find the appropriate link to download the file, a PDF based incident report or newsletter, he or she is interested in.
The Feedburner processed feed behaves identically, it can’t be read in iPad browsers but gets downloaded and presumably could be read in an appropriate reader app. It really isn’t an issue that affects any of the Institute’s users, just me lying in bed playing with my iPad.
Last edited by joebaich (2012-07-14 19:35:56)
Everything in that seems fine, and the feed does open properly for me in iOS’ Mobile Safari on iPhone. Well, after Apple has downloaded it on their servers. Mobile Safari itself doesn’t process feeds, but uses a middle man. Never opened a feed in Mobile Safari on iPad so don’t know if acts differently to its little brother or has any error scenarios to look for.
Apple, if I’m remember correctly, will be dropping build in support for feeds from desktop Safari in couple of days when Mountain Lion launches. Same could very well happen to iOS. This doesn’t mean nothing will open feeds, but you will be redirected, or have to relay, to a dedicated application.
Apple has certain limitation of what applications can do and be. On iOS you actually don’t have browser options. All of the browsers use Safari underneath, and can only change the GUI and behavior outside rendering and core browsing. The fact that every browser acts the same when you try to access the feed isn’t surprise; they are the same browser.
presumably could be read in an appropriate reader app
It can. And both Mac OS and iOS have number of good feed reader options, both web and application based. I personally prefer Reeder which syncs with Google Reader.
Last edited by Gocom (2012-07-14 20:06:17)
Thank you for your insight. Yup, my iPhone showed the feed as it should too once I checked after your last. So maybe just an iPad issue, or even just a my iPad issue. Not at all life threatening and your tip about Reeder really fixes it.
v1.0.1 released. Changes:
- Changed: Now doesn’t uninstall rah_eo_ prefixed form partials with the plugin. These forms could be used for something else than just as the plugin’s snippets.
- Dropped: code path used as a plugin cache fallback. Now relays on existence of plugin-lifecycle callbacks.
- Dropped: migration cleaner deployed in v0.6. Is no longer relevant.