<p>It's entirely possible it was the stuck tasks depending on how the task originally failed, how many (and which ones) were backed up behind it and how many (and what kind of) changes were made on the site while the tasks were stuck.</p>

<p>Hard to know with 100% confidence, though.</p>

CC BY-SA 3.0
2016-03-03T03:54:55.570Z
Thanks Brad. I've narrowed the timing down to the same day the tasks were run. One correction: the blocking task had a status of "running". I restored from an overnight backup, and this time deleted all the backup tasks before deleting the blocking one so as not to have a repeat episode.  I suppose the other problem I have to address is that stuck tasks are a regular thing for this site. They don't always show as failed but never go anywhere.
Jack McKenzie
CC BY-SA 3.0
2016-03-03T06:42:42.977Z
You can use this as a general starting point for debugging stuck tasks: https://craftcms.com/support/stuck-tasks
Brad Bell
CC BY-SA 3.0
2016-03-03T01:23:27.387Z
2016-03-03T01:23:27.387Z
Brad Bell
<p>On a local government website running Craft CMS a lot of in-body links are effected with the Link to an Entry function within the Redactor editor. I have encouraged the content editors to use this instead a directly coded URL on the basis that if the linked-to entry changes location the link will still work. So far so good until sometime in the last week around 140 of these internal links corrupted.</p>

<p>So what used to be</p>

<pre><code>&lt;p&gt;Please see &lt;a href="/council/publications/files/schedule-of-fees-and-charges#entry:1378:url"&gt;Schedule of fees and charges&lt;/a&gt;
</code></pre>

<p>became </p>

<pre><code>&lt;p&gt;Please see &lt;a href="{entry:1378:url}#entry:1378:url"&gt;Schedule of fees and charges&lt;/a&gt;
</code></pre>

<p>and of course no longer work.</p>

<p>Understandably there is a lot of upset, both around the fact that access to important documents is no longer available, and that fact that someone has to find and repair 140 links, and then check that they were repaired correctly.</p>

<p>Can anyone offer any suggestion as to how this may have happened? All I can offer is that a Pending Task held up the task list for a while (I don't know how long). The task hadn't failed but after seeing no action on it for a day or so, I deleted it and this caused a backlog of tasks to run. While I don't know if there was any connection, but the timing of the start of the problem does match the running of the tasks.</p>

<p>The links have also been changed in all the entry revisions. At first this made me suspicious that they were never right, but as we run a link checker looking for broken links around once a month, or whenever a bigger set of edits have been made, I can confirm that this change happened recently. This points me back to the tasks.</p>

CC BY-SA 3.0
2016-03-03T00:18:08.843Z
Totally guessing, but this might have something to do with it: [`It is now possible to include custom URL fragments in links to entries within Rich Text fields, alongside the entry's reference fragment`](https://craftcms.com/changelog#build2759)
Lindsey D
CC BY-SA 3.0
2016-03-03T00:19:12.627Z
Didn't post that as an answer because (a) it's a guess, and (b) I have no solution for you. Most likely, it'll require some manual repairs.
Lindsey D
CC BY-SA 3.0
2016-03-03T00:26:19.793Z
Thanks Lindsey. I'm not yet on that version (still on 2.5.2755). I tend to run behind because after an earlier update fail left the site down for 3 hours I tend to do it manually so I have everything ready to recover when update fails.
Jack McKenzie
CC BY-SA 3.0
2016-03-03T00:27:03.023Z
Smart move... and luckily, that rules out my theory!
Lindsey D
<redactor><richtext><link>
Corruption of Link to an Entry links within Rich Text field
# Corruption of Link to an Entry links within Rich Text field

(Asked by: username_0 on 2016-03-03)

On a local government website running Craft CMS a lot of in-body links are effected with the Link to an Entry function within the Redactor editor. I have encouraged the content editors to use this instead a directly coded URL on the basis that if the linked-to entry changes location the link will still work. So far so good until sometime in the last week around 140 of these internal links corrupted.
So what used to be
Please see Schedule of fees and charges

became 
Please see Schedule of fees and charges

and of course no longer work.
Understandably there is a lot of upset, both around the fact that access to important documents is no longer available, and that fact that someone has to find and repair 140 links, and then check that they were repaired correctly.
Can anyone offer any suggestion as to how this may have happened? All I can offer is that a Pending Task held up the task list for a while (I don't know how long). The task hadn't failed but after seeing no action on it for a day or so, I deleted it and this caused a backlog of tasks to run. While I don't know if there was any connection, but the timing of the start of the problem does match the running of the tasks.
The links have also been changed in all the entry revisions. At first this made me suspicious that they were never right, but as we run a link checker looking for broken links around once a month, or whenever a bigger set of edits have been made, I can confirm that this change happened recently. This points me back to the tasks.

**Tags:** redactor, richtext, link
> **Comments:**
> **username_1**: Totally guessing, but this might have something to do with it: [`It is now possible to include custom URL fragments in links to entries within Rich Text fields, alongside the entry's reference fragment`](https://craftcms.com/changelog#build2759)  
> **username_1**: Didn't post that as an answer because (a) it's a guess, and (b) I have no solution for you. Most likely, it'll require some manual repairs.  
> **username_0**: Thanks Lindsey. I'm not yet on that version (still on 2.5.2755). I tend to run behind because after an earlier update fail left the site down for 3 hours I tend to do it manually so I have everything ready to recover when update fails.  
> **username_1**: Smart move... and luckily, that rules out my theory!  

---

## 1 answers

### Answer by username_2 on 2016-03-03. Score: 1 | Accepted answer

It's entirely possible it was the stuck tasks depending on how the task originally failed, how many (and which ones) were backed up behind it and how many (and what kind of) changes were made on the site while the tasks were stuck.

Hard to know with 100% confidence, though.

> **Comments:**
> **username_0**: Thanks Brad. I've narrowed the timing down to the same day the tasks were run. One correction: the blocking task had a status of "running". I restored from an overnight backup, and this time deleted all the backup tasks before deleting the blocking one so as not to have a repeat episode.  I suppose the other problem I have to address is that stuck tasks are a regular thing for this site. They don't always show as failed but never go anywhere.  
> **username_2**: You can use this as a general starting point for debugging stuck tasks: https://craftcms.com/support/stuck-tasks  

---

