19 July 2011, 6:35

I'm new to Mahara, so please be gentle with me. 

A user deleted a collection and now gets the error "Collection with ID8 Not Found" when clicking on her pages that used to be within the collection. Have you any idea what could be causing this?

If not how can I get this back from a backup?

I've never done it before so any help would be grateful.

Thanks in advance,

James.

19 July 2011, 17:13

James, I'm able to reproduce this bug.  It happens when you include a navigation block into a page, and then delete the collection referenced by the navigation block.

I've filed a bug report here: https://bugs.launchpad.net/mahara/+bug/813204

In the meantime, deleting the navigation block that refers to the deleted collection will get you going again, but you'd have to do that directly in the database.  If the page has id 12345, do this:

DELETE FROM block_instance WHERE blocktype = 'navigation' AND view = 12345;

20 July 2011, 3:06

Thanks Richard.  It certainly sounds like it's the solution.

As I said earlier, i'm a total Newbie, so is there any chance you could give me step by step instructions on how to apply the fix?

Thanks,

James.

21 July 2011, 21:59

James, it really depends on how you access your database, the command I posted before assumes you're using some kind of terminal client like psql.

If you're using a graphical or web-based client to administer your database, then you need to find the row in the block_instance table that has the id of the page you can't edit in the 'view' column, the string 'navigation' in the blocktype column, and delete that row.

If on the other hand you want to fix the problem at the code level, you'll need to apply the patch linked to from the bug report. This will give you some ideas:

http://mahara.org/interaction/forum/topic.php?id=2199

Although, the patch hasn't gone to a stable branch yet, so the option of generating the tarball isn't there.

03 August 2011, 5:33

Hello Jemes, Hello Richard,

thank you Richard for the advice with the patch. I applied the patch from gitourios.org in a 1.4.0 installation and it works. ;-)

But the row in the block_instance table that has the string 'navigation' in the blocktype column and wich is related to the view will not deleted with this patch. This is intended?

Thanks,

michael w.

03 August 2011, 6:21

Hello Richard,

I am asking, because I get the following error-message after I've deleted a collection without deleting the navigation in a view before:

[Wed Aug 03 13:14:36 2011] [error] [client xx.xx.xx.xx] [DBG] 00 (blocktype/lib.php:687) Artefact not found when rendering a block instance. There might be a bug with deleting artefacts of this type? Original error follows:, referer: http://localhost/mahara/view/view.php?id=66
[Wed Aug 03 13:14:36 2011] [error] [client xx.xx.xx.xx] [DBG] 00 (blocktype/lib.php:688) Collection with id 21 not found, referer: http://localhost/mahara/view/view.php?id=66
[Wed Aug 03 13:14:36 2011] [error] [client xx.xx.xx.xx] [DBG] 00 (blocktype/lib.php:704) Cannot render block title. Original error follows: Collection with id 21 not found, referer: http://localhost/mahara/view/view.php?id=66

Thanks,

michael

03 August 2011, 17:29

Thanks Michael, good to know it works on 1.4 as well.

You're right that it just allows you to see and edit views with the bad blocks in them.  It doesn't ensure navigation blocks pointing at a collection are deleted when the collection is deleted.

It doesn't upgrade your database to remove any existing bad navigation blocks, so you will still need to either reconfigure or delete the blocks.

In my opinion it's not worth doing an upgrade to fix all the bad blocks, but you're right, we should commit another patch to try and fix navigation blocks when deleting collections.  I say 'try', because searching through the configdata column of all navigation blocks on the site is a bit horrible given the way that data is stored, and also could be an expensive operation.  We might want to live with just fixing navigation blocks inside the views belonging to the collection that's being deleted.

04 August 2011, 3:59

Hello Richars,

Thank you for your answer. I thought something like that. ;-)

greetings,

michael

02 August 2011, 18:52

The fix is good, but missing a step.

There is nothing on error page that tells us what the view number is. You have to dig into the database a little.

My error message is:

"Not Found

The page you are looking for could not be found

Collection with id 245 not found"

(I added the emphasis on "245".)

I had to run this query on my database to find the view number:
mysql> select * from block_instance where blocktype = 'navigation' and configdata like "%245%";
+-------+------------+-----------+------------------------------------+------+--------+-------+
| id    | blocktype  | title     | configdata                         | view | column | order |
+-------+------------+-----------+------------------------------------+------+--------+-------+
| 68929 | navigation | Fruit Nav | a:1:{s:10:"collection";s:3:"245";} |  438 |      1 |     1 |
+-------+------------+-----------+------------------------------------+------+--------+-------+
1 row in set (2.05 sec)

Then run Richard's database delete command, replacing his view number with your own. In my case, that would be 438.

03 August 2011, 1:16

Donna, that's true.  I guess I was thinking that you could get the id of the view from the url in the browser when you hit the error page (something like view/view.php?id=438 or view/blocks.php?id=438), but I guess there are going to be places when the view id isn't in the url.