I’ve been having a play with Xibo over the last few weeks using the API to change layouts. I’ve found that if a layout is created and published on the CMS (and assigned layoutID 1), then if the API does a checkout on the layout, the CMS still displays layoutID 1 as a draft, but the response of the checkout API call suggests the layoutID should now be 2. At this point, I can’t see a layoutID 2 on the CMS, nor can I publish layoutID 1 again.
The layout ID will change when you publish yes. It won’t necessarily be the next sequential number.
You can use the layout-specific campaign ID to reference the layout which remains constant over publishes, or you can search for the layout by name / tag etc to get the new ID after publishing.
Thank you for getting back to me on this. I understand that the LayoutID will change, but the problem that I’m facing is that when a checkout API call is made, the layout visible on the CMS remains the old layoutID.
That’s correct too. When you checkout, your existing layout remains in place, and a new copy is made for you to edit. When you publish, the copy replaces the original.
Ok - I think I’ve found the problem. When I call the publish call, the publishedStatus in the response still says ‘Draft’. I can’t tell why this isnt working. I’ve got the layoutID in the url, the access token is working and I’ve got a publishNow flag in the body. Any ideas?
Perhaps you’re publishing the draft rather than the parent?
It’s not my area of speciality, but if that’s not the case, if you post the full request you’re making (minus the authentication etc) and a screenshot showing the layout you’re editing in the layout grid, and the ID of the draft, then I can ask someone else to look for you.
In order to use the publish endpoint, you need to call it on the parent layoutID with a publishNow flag in a content type x-www-form-urlencoded. Without the publishNow flag the layout will not publish.