Unpublishing - how to make it stop trying to delete files that aren't there

Rhythmyx Technical Discussion
1

I’m wondering if anyone has an suggestions for something I’m seeing in our publishing process…

We have content lists/editions that publish and unpublish different content types. Occasionally, a file has already been deleted directly from the file system before its state is set to “Unpublished”. Rhythmyx still thinks the file is out there, and needs to be unpublished. It keeps including that item in the content list for unpublishing, and keeps logging an error when it can’t find the file.

Is there any configuration change I can make to tell it “if you don’t find the file, consider it unpublished and stop trying”?

Thanks for any and all suggestions -
Kathleen

2

Kathleen,

We had the same problem. This is what Percussion Technical Support suggested for us:

  1. Do a search on the RXSITEITEMS table for the CONTENTID, SITEID, and
    VARIANTID, then remove that item from the table, or
  2. If you have many items that are failing either because their locations
    have been changed or they’ve been removed directly from the webserver
    istead of through an unpublish, you could completely truncate the
    RXSITEITEMS table, delete all of the published items from your webserver,
    and then republish the entire site.

Method 2 is certainly more time intensive, but it’s the most thorough way
to go about fixing this issue. Regardless of the method you choose, I
recommend backing up your database before manually making any changes. If
something unexpected happens, this will be the best way to recover.

We went with method #2 as it ended up being the simplest solution for us.

  • Wimble
3

That makes sense - I suspected it would take some kind of manual intervention like that. We don’t have much content that’s causing errors, so I may try removing them one by one.

Thanks very much for the reply!

-Kathleen

4

The database schema After 6.6 changes so that it is no longer possible to delete items from the RXSITEITEMS table, its now just a view and is spread out among at least two other tables.

Does anyone have a “new” procedure for fixing “Orphaned” files that were deleted before they were set to archive or unpublished?

This is beginning to look like a very important but missing feature.

5

In 6.6, the content of original RXSITEITEMS table is reside in 2 other tables, PSX_PUBLICATION_SITE_ITEM and PSX_PUBLICATION_DOC

Deleting an entry in PSX_PUBLICATION_SITE_ITEM table in 6.6 should be equivalent as deleting an entry in RXSITEITEMS table before 6.6.

In 6.6, user will be able to “cleanup” the “site item” table for a particular site by selecting the “Delete Site Item Entries” menu button, which is one of the “Action” menus for the “Publishing Logs” node under each Site (in “Publishing Runtime” tab).

BTW, in 6.6, removing a file that has already deleted should be considered a successful “unpublishing”, so the original problem may not be an issue in 6.6.

-Ben

6

Ben,

Thanks for that information.

I see the option now, but did not know what it was for…

The context of your message however prompted me to ask this question.

Isn’t 6.6 already released?

7

Yes, 6.6 was released in Jan.

8

You could also change the pubstatus of the rxsiteitems entry to success from failure

9

You can also create a file on the destination webserver at the correct location, with the correct filename. Rhythmyx finds something to delete and is then happy.