Forums | Mahara Community

Support /
No 'filetype' in ArtefactTypeBlogPost


Howard Miller's profile picture
Posts: 191

26 August 2014, 3:10

I think I've asked a question vaguely related to this before, but I'm now doing some work to investigate it. 

I'm trying to view a page and get the following error...

[WAR] 65 (artefact/lib.php:425) Field filetype wasn't found in class ArtefactTypeBlogPost
Call stack (most recent first):
  • ArtefactType->get("filetype") at /var/www/maharabug/htdocs/artefact/file/blocktype/internalmedia/lib.php:53
  • PluginBlocktypeInternalmedia::render_instance(object(BlockInstance), true) at Unknown:0
  • call_user_func_array(array(size 2), array(size 2)) at /var/www/maharabug/htdocs/lib/mahara.php:1562
  • call_static_method("PluginBlocktypeInternalmedia", "render_instance", object(BlockInstance), true) at /var/www/maharabug/htdocs/blocktype/lib.php:661
  • BlockInstance->render_editing() at /var/www/maharabug/htdocs/lib/view.php:2009
  • View->build_column(1, 2, true) at /var/www/maharabug/htdocs/lib/view.php:1966
  • View->build_columns(1, true) at /var/www/maharabug/htdocs/lib/view.php:1951
  • View->build_rows(true) at /var/www/maharabug/htdocs/view/blocks.php:270
Checking out artefact/file/blocktype/internalmedia/lib.php, it pulls a record from the database with an 'artefacttype' of 'blogpost'. This results in an object of type ArtefactTypeBlogPost being instantiated. The code next attempts to get('filetype') from the object. Unfortunately this class doesn't have a field called 'filetype' so we crash and burn. I'm a bit unsure if this is a bug or there's something odd in my database. 
Robert Lyon's profile picture
Posts: 756

26 August 2014, 9:48

Hi Howard,

Hmm, this is an odd one.

According to the code the artefact is fetched within the render_instance by this line:

 $artefact = $instance->get_artefact_instance($configdata['artefactid']);

So if the 'artefactid' in the configdata is wrong then it will cause this error. How that number got to be wrong I'm not sure.

But if you have a look at the block_instance table in the database and find the block trying to be rendered there will be some serialised configdata that relates to it.

In that serialised date there will be a pattern similar to:

 s:10:"artefactid";s:1:"6";

Where the last number is the id of the artefact it is trying to render.

Try changing that to the id of the internalmedia artefact you are trying to display

So for example the id you want to show is 1234 you'll need to change that bit to:

 s:10:"artefactid";s:4:"1234";

The s: is followed by an integer indicating the length of the following value so if your id is longer or shorter than 4 digits you will need to adjust that s:4 to be the length of the value.

That should now render the correct artefact when the page loads.

Note: Make sure you take a copy/backup of that block_instance's configdata before starting just in case.

Cheers

Robert

 

Howard Miller's profile picture
Posts: 191

26 August 2014, 20:28

I've had a few users reporting what looks like a similar problem. It happened after an upgrade from 1.6 to 1.9. It also (probably not surprisingly) breaks export. 

I'm at a disadvantage in that I don't know what the block is supposed to look like - they're not my pages. 

I'll keep digging. I don't know my way around the Mahara code and database especially well so it's a bit of a learning curve :)

I'm working with a copy of the live site, so it doesn't matter if I break it at this stage

Howard Miller's profile picture
Posts: 191

26 August 2014, 20:48

Ok, if I look at the block_instance table for the offending View, I have...

select id,blocktype,configdata from block_instance where view=19689;+-------+---------------+--------------------------------------------------------------------------+| id    | blocktype     | configdata                                                               |+-------+---------------+--------------------------------------------------------------------------+| 90282 | blogpost      | a:2:{s:10:"artefactid";i:150190;s:8:"copytype";s:6:"nocopy";}            || 90283 | internalmedia | a:3:{s:10:"artefactid";i:150234;s:5:"width";s:0:"";s:6:"height";s:0:"";} || 90284 | internalmedia | a:3:{s:10:"artefactid";i:150235;s:5:"width";s:0:"";s:6:"height";s:0:"";} || 90285 | internalmedia | a:3:{s:10:"artefactid";i:150229;s:5:"width";s:0:"";s:6:"height";s:0:"";} || 90286 | internalmedia | a:3:{s:10:"artefactid";i:150226;s:5:"width";s:0:"";s:6:"height";s:0:"";} || 90287 | internalmedia | a:3:{s:10:"artefactid";i:150231;s:5:"width";s:0:"";s:6:"height";s:0:"";} || 90288 | internalmedia | a:3:{s:10:"artefactid";i:150236;s:5:"width";s:0:"";s:6:"height";s:0:"";} || 90289 | internalmedia | a:3:{s:10:"artefactid";i:150228;s:5:"width";s:0:"";s:6:"height";s:0:"";} || 90290 | internalmedia | a:3:{s:10:"artefactid";i:150233;s:5:"width";s:0:"";s:6:"height";s:0:"";} || 90291 | internalmedia | a:3:{s:10:"artefactid";i:150232;s:5:"width";s:0:"";s:6:"height";s:0:"";} |+-------+---------------+--------------------------------------------------------------------------+

It's failing on the first internalmedia block with id=150234 (presumably just because it is first.

If I look up 150234 in the artefact table I get this...

 select * from artefact where id=150234\G
*************************** 1. row ***************************
             id: 150234
   artefacttype: blogpost
      container: 0
         parent: 150225
          owner: 14205
    institution: NULL
          group: NULL
          ctime: 2012-07-20 14:22:38
          mtime: 2012-07-20 14:22:38
          atime: 2013-03-22 14:24:28
         locked: 0
          title: 1.mp4
    description:
           note: NULL
         author: 14205
     authorname: NULL
  allowcomments: 1
approvecomments: 0
        license: NULL
       licensor: NULL
    licensorurl: NULL
1 row in set (0.00 sec)

Is this right? I'm not sure how this is supposed to work but we seem to have gone from an 'internalmedia' entry in block_instances to a 'blogpost' in the artefact table.

Am I right in thinking that the 'instance' (i:) in the configdata should point to an artefact with an artefacttype compatible to the blocktype in the block_instances row (e.g. video in this case)?

Howard Miller's profile picture
Posts: 191

27 August 2014, 0:17

Just to add... I dug out a copy of the database that we made just before we upgraded to 1.9 - we were running 1.6. The data in those tables is identical, so the upgrade didn't change anything. 

I'm very confident that it all worked in 1.6 so....

Howard Miller's profile picture
Posts: 191

27 August 2014, 3:03

Another add... I thought I'd better be 100% and I reloaded the complete 1.6 site from backups on my test server. I get the SAME ERROR in 1.6, just slightly different line numbers. So this seems to go back a while. 

Robert Lyon's profile picture
Posts: 756

27 August 2014, 11:31

Hi Howard,

Thanks for that information - I'll try and see if I can replicate the error and let you know which is incorrect the info in the block_instance table or the information in the artefact table - and hopefully how to fix it.

Can you let me know if the mahara 1.6 instance was the first installed or was an earlier version installed which has been upgraded to 1.6 at some point?

Cheers

Robert

 

Robert Lyon's profile picture
Posts: 756

27 August 2014, 14:27

I've not been able recreate this issue (besides manually changing the configdata in the database).

So I'm wondering if you could also also supply the view_artefact information that relates to the view this block is on and any artefact_file_files information as well

Cheers

Robert

 

Howard Miller's profile picture
Posts: 191

27 August 2014, 21:38

This is a site that has been around for a long time. I think initially 1.2. We've had a few fun and games with the schema getting out of sync. However, this user is new enough that I know this view can only have been created on the 1.6 instance. Just to reiterate - this doesn't seem to be an isolated incidence although this appears to be the only one I have the view id for. I'll see if I can collect some more (otherwise, I'd just delete it and hope for the best).

Here's the view_artefact records...

 select * from view_artefact where view=19689;
+-------+-------+----------+-------+
| id    | view  | artefact | block |
+-------+-------+----------+-------+
| 80369 | 19689 |   150190 | 90282 |
| 80370 | 19689 |   150234 | 90283 |
| 80371 | 19689 |   150235 | 90284 |
| 80372 | 19689 |   150229 | 90285 |
| 80373 | 19689 |   150226 | 90286 |
| 80374 | 19689 |   150231 | 90287 |
| 80375 | 19689 |   150236 | 90288 |
| 80376 | 19689 |   150228 | 90289 |
| 80377 | 19689 |   150233 | 90290 |
| 80378 | 19689 |   150232 | 90291 |
+-------+-------+----------+-------+

There was nothing in artefact_file_files for artefact=150234. I checked block_instance for id=90283 which seems to agree...

select * from block_instance where id=90283\G

*************************** 1. row ***************************        
id: 90283 
blocktype: internalmedia     title: Piano Duet
configdata: a:3:{s:10:"artefactid";i:150234;s:5:"width";s:0:"";s:6:"height";s:0:"";}     
view: 19689   
column: 2    
order: 1      
row: 1
1 row in set (0.00 sec)
Robert Lyon's profile picture
Posts: 756

28 August 2014, 8:19

I've written a little script to help find the mismatched items, it can be downloaded from here: script-to-check-for-mismatched-block-artefacts

It doesn't fix the problem but will give you an overview of what type of blocks are getting broken.

Hopefully there will be a pattern to help diagnose the problem.

Also - do you have any customisations or is it a plain install of Mahara?

Cheers

Robert

15 results