Hi Torsten,

Hmm, that's kind of weird. Do you have a database backup?

If so, are you comfortable inspecting the QueuePageDuplicationRelations table in your database (with phpMyAdmin, command line or similar) and seeing if it's empty? I skimmed concrete/tools/dashboard/sitemap_copy_all.php and at first glance it seems like that table is used during the copy process and then truncated (wiped out).

I wonder if you have some entries in there?

Hi Matt, I couldn't find a QueuePageDuplicationRelations table in the database...

Hello,
You can probably just clear that entire queue if it's stuck like that. As always please make a database backup first.

Disable the Overrides Cache.

Create a tools file
/tools/clear_copy_queue.php
Add this code


Execute the tools file by navigating to(replace example.com with your site)
[code]
http://www.example.com/index.php/tools/clear_copy_queue...

You may also need to click the "Reset All Jobs" button in the Jobs page in the Dashboard after that.

Best Wishes,
Mike

Hi Mike, I tried that and i think it clears that queue but (after resetting automated jobs) the notice (like on the image) still appears. But starting the copy process again shows first the status bar (what it didn't before clearing) and then the error message (as you see in second image).

My problem is that I can't remove the notice in sitemap.

Best regards

Torsten

Hi tsilbermann

Did you ever resolve this please? I have the same issue and mkly's code didn't have any effect on the actual dashboard message for me either.

There's probably a value or two can be changed in the database I imagine.

I may have to restore a C5 dbase backup in my case but this doesn't seem to be a practical solution on a site with many editors if it happens again in the future.

Many Thanks
Gordon

Hi Gordon,
no, I didn't resolved it.

Best,
Torsten

Thanks for replying anyway.

Gordon

In case this helps out others, here’s how I fixed it.

DISCLAIMER: I’m not a C5 expert, so proceed with caution. Manually removing records from tables is probably not the smartest solution.

I’m on 8.5.0 with PHP 7.2.

I had the same error on my sitemap page: “Page copy operations pending” with a “Resume Copy” button. Clicking the “Resume Copy” button resulted in an error: “{"error":{"message":"Invalid token. Please reload the page and retry."},"errors":["Invalid token. Please reload the page and retry."]}”

In addition, this error was preventing me from doing any page duplication on the site — I could copy individual pages, but I could not copy a page and its children without getting an error like this:

```
An exception occurred while executing 'INSERT INTO Pages
(cID, siteTreeID, ptID, cParentID, uID, cOverrideTemplatePermissions, cInheritPermissionsFromCID, cInheritPermissionsFrom, cFilename, cPointerID, cPointerExternalLink, cPointerExternalLinkNewWindow, cDisplayOrder, pkgID) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)' with params [3576, "1", null, 3526, "1", null, null, null, null, 0, null, null, null, null]:

SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'ptID' cannot be null
```

—-

I. Diagnosing

The “Page copy…” error is displayed by `concrete/single_pages/dashboard/sitemap/full.php:32`.

```
$u = new User();
if ($u->isSuperUser()) {
if (Queue::exists('copy_page')) {
$q = Queue::get('copy_page');
if ($q->count() > 0) { ?>
<div class="alert alert-warning">
<?=t('Page copy operations pending.')?>
<button class="btn btn-xs btn-default pull-right" onclick="ConcreteSitemap.refreshCopyOperations()"><?=t('Resume Copy')?></button>
</div>
<?php }
}
}
```

It looks like it’s being displayed because a ‘copy_page’ item exists in the Queue.

Queue is use Concrete\Core\Foundation\Queue\QueueService: `concrete/src/Foundation/Queue/Queue.php`


II. Database diving

I used phpMyAdmin to look at the database. In 8.5.0 there are three “Queue”-related tables.

1. Queue
2. QueueMessages
3. QueuePageDuplicationRelations

Sure enough in Queues, the last record has a queue_name of `copy_page` and in my case, a queue_id of `308`.

Looking in QueueMessages, the last record has a queue_id of 308. (There were other queued items as well). The time stamp of the record matched the time that this problem first cropped up.


III. Surgery

Going off of what `mkly` suggested, I decided to try to just purge the offending records.

1. Backup the database!
2. Use phpMyAdmin to log into the database
3. Export the Queues and QueueMessages tables (just in case we need to do a quick restore)
4. Delete the problem `308` records in Queues and QueueMessages.

This appeared to fix all the problems:
a. “Page copy pending…” message did not appear any more.
b. I could duplicate pages with children again.

Is there a safer way to do this?

Hi Benloh

I don't know if there's a safer way to do it but your method worked for me.

Well I say it worked, I had to be even more brutal as just deleting the trouble records didn't work. I ended up truncating the three tables and that did the trick.

The queue messages table had thousands of records.

Good work and thanks for posting you working too. Helped me!

Cheers
Gordon

Glad it worked for you Gordon!

I actually have an additional problem with "This page is pending a move beneath..." messages being displayed on some of the moved/copied pages that won't go away in spite of the queue removal. So I'm still working on that one. It might be related to workflows.

I haven't encountered that one. This chat also helped my overall issue with the database if there's anything in there that might help.

https://www.concrete5.org/community/forums/usage/cant-empty-the-tras...

Analysing the code as you have will obviously get you there again. Another longer hand way might be finding the cIDs of the problem pages and looking for tables that reference the cID and seeing if there's any strange patterns or potential anomolies. It's worked for me a few times.

Ah, that's really helpful! Thanks!

For the record,,,

The "This page is pending a move beneath..." messages that wouldn't go away were triggered in `concrete/src/Workflow/Request/MovePageRequest.php`

There are two db tables involved:
* PageWorkflowProgress
* WorkflowProgress

To resolve:
1. Backup the db
2. Export the tables for a quick restore
3. Identify the two page iDs that had the error (e.g. 3202 and 3517).
4. Look in PageWorkflowProgress for the wpIDs related to the two pages (e.g. 3202:6166, 3202:6167, 3202:6169, 3517:6168)
5. Remove the records in WorkflowProgress with the corresponding wpIDs (e.g. 6166, 6167, 6168, 6169).
6. Remove the corresponding records in PageWorkflowProgress as well.

This seemed to remove the messages.

DISCLAIMER: Again, I'm just reporting what I tried/hacked and what seemed to work for me. Your mileage may vary.