We are using an Blog List widget for our events listing page. However, why are our event articles scheduled to have been removed from site still appearing on our events lists page, post the removal date and times. Yet clicking on the event’s link takes you to the missing articles error page? Can someone please assist?
Hey Mike,
What is your process for archiving the old events? Are you simply using the scheduled removal feature and performing no other actions, or are there additional / different steps such as relocating the page, deleting the page and running a full publish, or something else?
If it’s the first case and you haven’t relocated or deleted the page, what happens if you manually republish and then unpublish one of the event pages that is erroneously appearing on the listing page?
Hi Nathaniel,
At first I was just using the scheduled removal feature and nothing else. I have since re-published and tried to manual remove from site again. but it still appears in the list.
So if the is there no way to automatically have the article drop off the live website if its featured in an auto Blog List?
No, the first case (using scheduled removal) should definitely work. I was just troubleshooting.
Thanks for testing that, Mike. Can you take a peak in your publishing logs section (Publish > Reports > Publishing Logs) and let me know if either the recent publish or unpublish operation Failed or Completed with Failures (if so, please click on View Details and share the full error)? Thanks.
Yes there have been a few errors actually,
heres one:
Error for metadataEndpoint: perc-metadata-services/indexer/entry, Item: 10,329,396,349,509, jobId: 1,478, location: D:/Percussion-DTS/Deployment/Server/www.c2c-online.co.ukapps/ROOT/days-ou…, contentType: text/html;charset=UTF-8, length: 76,323 caused by unknown error: Unable to connect to delivery server at: https://localhost:8443.
Mike, you’re no longer publishing to a local Tomcat server, are you? Because it appears that CM1 is still pointing back to your local Tomcat server to write out and remove indexed meta-data information (“Unable to connect to delivery server at: https://localhost:8443”).
Please have your server admins look at this doc, taking close note of steps 3 and 4, to make sure DTS integration is setup correctly for your new publishing location:
Also, can you share a link to a page on your published server where this blog list is located, so I can get a better idea as to how DTS is currently configured?
Nathaniel,
it looks like a half-dozen items have been deleted without successfully unpublishing from the DTS tables.
What is the correct approach to clearing out these entries?
Since the site is not yet live, we could as a one-off exercise stop all the services, clear out all the DTS tables, restart and have a full site publish rebuild them?
But going forward, is there a recommended approach for making these types of in-life adjustments?
Thanks,
Oliver
Hi Oliver,
Yes, you can safely reset the contents of your DTS tables using the process you outlined (you could even drop the tables entirely – they’ll get rebuilt when the DTS service starts back up), and then run a full site publish to sync your DTS database back up with the workflow state of content in the CMS.
It’s not uncommon for content can get orphaned in this way during the development / configuration process, as servers will be going offline and online, and publishes may get run while the DTS server is not 100% operational.
You shouldn’t see this very often once you go live and your systems are always online, but if you do, the safest way to clear out orphaned content would be to simply recreate the content in the exact file location that’s being referenced by your DTS powered widget (maintaining the exact file name), and then manually publish and then unpublish the content.