Publishing non-content from the CMS

I have recently upgraded a 5.7 system to 6.7 and am getting everything back up and working again. One thing we had in 5.7 was a few custom made publishing content lists that published out files that were not actual CMS content item templates (variants)

One example is a ‘publishing_complete.txt’ file which is published at the end of an edition - and this file is monitored on the webserver and when it appears, the front end flushes its page caches and then deletes the publishing_complete.txt file, and awaits a new one to appear at some point in the future.

We have a custom content list created from an XML resource and the content URL is:

http://localhost:9992/Rhythmyx/my_custom_app/publishing_complete.html

This all works perfectly and has done for many years.

That is, until 6.x came along…

We now get a ‘[PSPublishingJob] Bad content url found: http://localhost:9992/Rhythmyx/my_custom_app/publishing_complete.html’ error message whenever we try and publish.

From some investigation it seems that all content URL’s must have /assembler/render/… in them. I’m just wondering what the most efficient way of doing this is.

I could have a new content type called ‘static_url’ or similar, with a single field (URL). For this example I would create the content item and set the URL to be ‘…/my_custom_app/publishing_complete.html’

I’d then create a template (or variant) that just takes the URL from the content item and calls that (in XSL I’d use a document() call here).

Another option would be to make some additional template registrations for each static url I want to publish out and set the assembly URL for them in the registration to be …/my_custom_app/publishing_complete.html or similar.

Has anyone else come across this type of requirement or have any suggestions on how better to do what I’m doing.

Thanks,

David

David,

I’d probably approach this by writing a batch/script file that handles this functionality and call it via the sys_editionCommandTask. Especially since the ContentLists are processed in parallel now and added to the queue as they’re processed. There’s no guarantee that the item in the “last” content list will actually be published last.

M.