I'm writing tests for aggregator.module and noticed that menu_link_maintain() dies with a fatal error when called with $op update.

The reason is that $item is now an object, it was an array before and has not been converted in #320510: [DBTNG] revamp menu.inc with DBTNG syntax.

A test is not yet included, you can reproduce the issue by enabling the aggregator.module, create a category and then update it. it will die with an fatal error.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

mr.baileys’s picture

Status: Needs review » Reviewed & tested by the community
Issue tags: +Quick fix

Confirmed bug, reviewed patch, applied patch, all good...

pwolanin’s picture

Status: Reviewed & tested by the community » Needs work

No, I disagree - we made a choice to handle all menu links as associative arrays at all stages for consistency - hence the query should be altered to fetch associative arrays.

This is a bit ugly, but apparently is the way to do it for DBTNG:

$result = db_select('menu_links', NULL, array('fetch' => PDO::FETCH_ASSOC))
pwolanin’s picture

Or Crell suggest we can use:

$result->setFetchMode(PDO::FETCH_ASSOC); 

before the foreach.

Berdir’s picture

Updated patch, it does now use fetchCol().

Berdir’s picture

Status: Needs work » Needs review

Setting to needs review again.

pwolanin’s picture

Hmm, looks ok - though not sure we've used that method much - I had to look at the doxygen to see what it does - I was confused with fetchField()

Can you double-check that this is correct if there are multiple rows in the result set?

Berdir’s picture

Updated:

- Added some tests for menu_link_maintain(). Including adding, updating multiple links in different menus and delete
- Added a groupby to the query which loads the updated menus, we don't need to clear the cache of a menu multiple times.

Status: Needs review » Needs work

The last submitted patch failed testing.

Berdir’s picture

Status: Needs work » Needs review
FileSize
4.31 KB

Forgot to add the change in menu_test.module...

pwolanin’s picture

sure - guess there is no reason not to group the results.

pwolanin’s picture

Status: Needs review » Reviewed & tested by the community

new tests pass, looks good.

Dries’s picture

Status: Reviewed & tested by the community » Fixed

Committed to CVS HEAD. Thanks.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

agentrickard’s picture

Status: Closed (fixed) » Needs work

This is actually still broken, IMO. Since the update $op doesn't use menu_link_save(), we can't get expected results for patches like #457450: Adds hooks to track changes to {menu_links}.

Shouldn't we just be calling menu_link_save()?

agentrickard’s picture

OK. Here is a revised version of the patch which standardizes the 'update' op to use menu_link_save().

I think if we don't use menu_link_save() in both cases, then we have written an exception handler, not an API function.

agentrickard’s picture

Status: Needs work » Needs review
pwolanin’s picture

I'm still not clear why we'd need to track the change if all that's changing is the title - are you going to update the node title based on this?

agentrickard’s picture

Possibly. Who knows what someone might want to do with the information. And, technically, not just nodes might use this function.

pwolanin’s picture

Probably premature optimization, but it would be nice to then tell menu_link_save that there are only title/options changes and that all the hierarchy info can be assumed to be correct as-is. Otherwise, we are doing a lot of work to make this change to one field. Still, I understand from a consistency standpoint why it's preferable.

agentrickard’s picture

Status: Needs review » Fixed

I'm going to set this issue back to fixed and address this change over in #457450: Adds hooks to track changes to {menu_links}.

Status: Fixed » Closed (fixed)
Issue tags: -Quick fix

Automatically closed -- issue fixed for 2 weeks with no activity.