You're going to have to give a lot better reproduction instructions to get anywhere with this one. Assuming you mean JInstallerAdapterComponent::_removeAdminMenus() and not some custom code the query in question already filters on admin menu items only (ordering is irrelevant here unless you're only looking for parent items and will rely on the JTable API to delete its children).

Also the left/right values should be updated so as to ensure the nested data set is correct, I'd advise against not executing that query.

If a frontend menu item is being assigned as the child item of an admin menu item, that is a major error with how the menu items are being inserted. Considering the data set you're giving is nothing but a bunch of IDs, it's hard to say what's going on.

Hi Michael,

Sorry to be unclear. Yes, you are right. I'm referring to JInstallerAdapterComponent::_removeAdminMenus().

No, a frontend menu item is not being assigned as the child item of an admin menu item. Menu items are consistent.

The error is found when _removeAdminMenus() is executed with a list of admin menu items not ordered by ID.

I think that the main clue of the problem is that JTableNested re-arranges lft and rgt values ... and parent node keeps the same values until the end... when it has invalid values.

I'm going to try to reproduce it in a Joomla demo site.

Addtionally, I can only reproduce it in Joomla 3.6 RC.

There is no problem with the SQL query of the method
_removeAdminMenus

if this bug exists it must be a problem with method ?

JTableNested::delete

is this change relevant ?
2819529

Hi @ggppdk , Yes, it's related with that modification.

I've found how to reproduce the issue with Weblinks.

The key to force the bug is in the order of menu items.

1. Modify _removeAdminMenus to force an inverse order of deletion, libraries/cms/installer/adapter/component.php, line 1087

   // Get the ids of the menu items
   $query = $db->getQuery(true)
               ->select('id')
               ->from('#__menu')
               ->where($db->quoteName('client_id') . ' = 1')
               ->where($db->quoteName('component_id') . ' = ' . (int) $id)
               ->order('id desc');
   

2. Install Weblinks.

3. Manually add a menu item (any type)
4. Install Weblinks again.
5. New menu item is removed!

Hi @wilsonge , please, check this issue that removes menu items.

Ok @anibalsanchez @mbabker
i confirm the issue of wrong menu items being deleted !

• a fix is to move the $table->rebuild() inside the deletion loop, thus executing a rebuild after every menu deletion

Is this performance unwise ? maybe rebuild() can be changed to be limited to a subtree ?

Also the bug, seems to be a side effect of the changes made to:
JTableNested::delete()

• now rebuild() is required to be called after every deletion ?

was this required before ?

is there other code similar to _removeAdminMenus() ?
are there 3rd party extensions that can be using similar code ?

This is a release blocker ?

Yes. It is a release blocker.

This a case about menu items, but it could also affect other cases
associated with nested table usage.
On Jul 7, 2016 8:53 PM, "Georgios Papadakis" notifications@github.com
wrote:

Ok @anibalsanchez https://github.com/anibalsanchez @mbabker
https://github.com/mbabker
i confirm the issue of wrong menu items being deleted !

• a fix is to move the $table->rebuild() inside the deletion loop, thus executing a rebuild after every menu deletion

Is this seems performance unwise ? maybe rebuild() can be changed to
limited to a subtree ?

Also the bug, seems to be a side effect of the changes made to:
JTableNested::delete()

• now rebuild() is required to be called after every deletion ?

is there are other code similar to _removeAdminMenus() ?
are 3rd party extensions that can be using similar code ?

This is a release blocker ?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#11044 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAXi9PnLyZegQAQ7ntF0L7sw7j7pe39eks5qTUs5gaJpZM4JHJzK
.

I've set a release blocker label and pinged the maintainer team in glip to make them aware. I'm away on holiday until saturday evening. If no one picks up on it by then, I'll deal with things here on my return

Set to "closed" on behalf of @infograf768 by The JTracker Application at issues.joomla.org/joomla-cms/11044

closed as we have a patch