@prh47bridge on backup of your site test #15806

@wojsmol - Happy to give that a go but not entirely clear how I do that? Do I need to use a different update server and, if so, how do I change that? Or is there another way to do it?

Thanks

See https://docs.joomla.org/Help37:Components_Joomla_Update#How_to_Access set update channal to Custom and Custom URL to http://jamp.joomla.pl/update-joomla-server/list.xml then click Save & Close. Obserse URL chenge and run update. Teport result in https://issues.joomla.org/tracker/joomla-cms/15806. After testing remember to cheange update channal to Default.

@prh47bridge if suggestion of @wojsmol helps, please close Issue, thanks.

@franz-wohlkoenig See #15806 (comment) and below.

thanks for info @wojsmol – so i let this Issue open or is #15806 a discussion about same Issue?

#15806 (comment) and below.is diferect issue from rhis described in #15806 but ralated to menu and cousing the same effect.. So #15806 So 1 good test is missing for RTC in #15806.

so it makes sense to let this issue stay open.

I'd already done that. I have, however, found the issue. Putting some messages in libraries/joomla/tables/nested.php revealed that Joomla thought a parent was unpublished. Using the SQL query the code uses identified that there is a rogue item in my menus table with title com_banners_categories, alias Categories, path joomla-license/Categories, link index.php?option=com_categories&extension=com_banners, published 0, parent_id 2, level 2, component_id 6, access 0, img class:banners-cat, lft 448, rgt 935 and client_id 1. There appear to be 8 items that are similar to this and are clearly different to any menu items I have set up. The lft and rgt values are clearly what is causing the problem on this item - they are more sensible on the other items, with rgt being lft+1 for all but one of them. JTableNested clearly thinks the rogue item is a parent to my menu items although it isn't in the hierarchy shown in the back end.

With 3.6.5 I can't see this item in the back end at all. With 3.7 I can see it if I select Administrator rather than Site menus. However, if I delete it a pile of menu items I need are deleted with it, so I'm not going to try that on the live site!

Looking at another site I manage I can see a similar set of menu items but the lft and rgt values make more sense. The one I have highlighted plus possibly one other item on the site where I have the problem have clearly been corrupted at some point.

The query used by 3.6.5 to identify unpublished parent items is slightly different to the one used in 3.7. This appears to be what makes the difference in behaviour.

As a developer, my view is that it would be risky to assume that my site is the only one that has this problem so it would be good if JTableNested could cope with rogue items like this, especially since it seemed to be ok in 3.6.5. It would also be good if there was a way to fix the underlying problem.

Any ideas as to what I should do about this apparently corrupted item?

Attached is a partial dump of #_menus. id 276 is the one that is causing problems. the lft and rgt values on id 275 also look a little suspicious and I'm not entirely sure about 274 either, although that could be ok. I can give you a full dump of this table if it would help. It has 279 rows currently. There doesn't appear to be anything I would regard as confidential in the table.

@prh47bridge no attachment, try with the txt extension.

Sorry - I think I forgot to attach!

There should be two files attached. dump.txt is the relevant entries in the database as it is today on the live site (3.6.5, so before upgrade) and dump_37.txt is the same entries on the test site after upgrading to 3.7.

dump.txt
dump_37.txt

1. On a test site restore to 3.6.5.
2. Check menutype of menuitem with id = 276. If menutype = mainmenu proced to 3 else break.
3. Run this query

UPDATE `#__menu` SET `menutype` = 'main' WHERE `id` = 276;

where #__ is a table prefix
4. Run menu rebuild from backend.
5. Run Joomla! update.

That has worked.

Looking at the database, the items in the SQL dump now all have published set to 1 apart from id 275 which now has published set to -2. They also all have menutype set to main following the upgrade - it was menu previously for all of them apart from 276. The lft and rgt values are still the same so I still have a pile of menu items which will be wrongly detected as children of item 276 but, as it is now published, that won't have any negative side effects.

This works as a specific fix for my site but it clearly isn't a general fix. Should I use this to upgrade my live site or wait for a more general fix? Do you want me to keep a copy of the 3.6.5 version of the site for further testing?

On a test site set published = 1 for menuitem withid 275 and then check admin menu for banner component.

The banner component is already showing in the admin menu. Setting 275 to published = 1 makes no difference - I still have the banner component in the admin menu. However, the database entries now look similar to those for the other site I manage, the only significant difference being that on that site rgt is always lft+1 for these rows.

I had the same problem.

I solved by excluding some tables:

That contemplate alias whit bar

example:
Contact/contacts
Contact/categories

I left only the main

EX: Contact

This error in the database happened when I upgraded from 1.5 to 2.5.

After upgrading to 3.7 it got worse as it does not allow me to Publish new menu items.

Sorry for the translation.

Having the same issue as others with the 3.7.1 update along with code from an extension completely wiped out, my template doesn't look right (tried to install it again along with a different template and neither looked or functioned correctly. Update is littered with issues. Of course the menu items that are unpublished are the ones that allow users to purchase a membership so I'm losing sales due to this. Reverting to 3.6.5 until they get this sorted out.

Send a printscreen in the table #menus

Envia um printscreen da tabela #menus

Returning to this and looking at my database again, the rgt value on item 276 is far too high at 937. The next highest rgt is 553 on the root menu item. The lft value is identical to the rgt value for another menu item which I believe is also wrong. The lft and rgt values on item 275 are identical to the values for another menu item. I'm pretty sure that is wrong too. So these values have somehow become incorrect and rebuilding the menu does not correct them.

Having reviewed the lft and rgt values on the whole table, these two items are clearly wrong. The rest of the entries follow a nice nested sequence. These just cut across that completely. The simple thing would be to renumber them to come on the end of the sequence and modify the rgt value for the root item so that they are children of it. That isn't perfect, however, as it would leave them in the wrong position on the main menu.

I think what is needed for this issue is a routine that fixes lft and rgt values recognising that items in menu x cannot be children of items in menu y and that admin items cannot appear in a non-admin menu.

Scrub that last comment. I've now figured out why rebuild isn't fixing the problem. Both the faulty menu items have parent_id set to 2. There is no item in the menu table with an id of 2 so JTableNested::rebuild isn't picking these items up and fixing the lft/rgt values. I'm going to fix my problem by setting the parent_id to 1 (which is the root item). The permanent fix would be to modify rebuild to detect orphaned items like this and make them children of the root item before it sorts out the lft/rgt values.

@prh47bridge Try find a proprt parent id.

Looking at my other site, these items are showing parent_id 2 and level 2 - on this site one of them is showing as level 0 which is definitely wrong. That site doesn't have an item with id 2 either. It looks like they should be children of an item with alias joomla-license. There is no such item.

Looking at my two sites it appears there used to be an item on the admin menu with alias joomla-license and sub-items Banners, Categories and Tracks. At some point this has been deleted but the child items are still in place - all three of them on one site, just Banners and Categories on the other. My other site also has a number of additional orphaned items - News Feeds/Feeds, News Feeds/Categories, Messaging/New Private Message and Weblinks/Categories.

I'm guessing these are remnants from when the admin menu structure was different. They don't appear to be doing anything useful. Perhaps, rather than set the parent_id to 1, these items should simply be deleted.

If we working on db from #15938 (comment) then for id 275 proper values are:
path = Banners/Banners
parent_id = 274
level = 2
and for all com_banners related menuitems paremt_id shoud be 274.

That's the one.

Having taken a look at the SQL script for a fresh install it is clear that you are right. It seems I should have sub-menus for Banners, Contacts, Messaging and News Feeds. None of those sub-menus appear in the Components menu on my back end. I have incorrect database items for two of the missing entries (Banners/Banners and Banners/Categories) but others are just completely missing from the database. It seems I've got some work to do to get the #_menu table into a good state. Perhaps what I really need is something that weeds out the incorrect entries and creates the correct set of items for the Components menu. My other site has rather more of the required entries in the database but they are not linked correctly.

The way it is isn't the end of the world. I can get to the things that should be on the Banners sub-menu by going to Banners where they are listed down the left. But this is not ideal.

These sites started with 1.5 or 1.6. I think I skipped 1.7 and went straight to 2.5. I wonder if this went wrong during one of the upgrades?

It now looks like what I should do to sort this correctly is fix 274 and 275 to show the correct parent_id, level and path, add the missing entries (Banners/Clients, Banners/Tracks, Contacts/Contacts, Contacts/Categories, Messaging/New Private Message, News Feeds/Feeds, News Feeds/Categories) at the end of #_menu manually, run a rebuild, then check the admin menu looks right and the database also looks correct. Does that sound right to you?

@prh47bridge That sounds like a good plan.

Ok, I've sorted both my sites now. Both had entries missing that should appear on the Admin Components menu. Both had items that showed parent_id that would have been correct on a fresh installation but were not correct on my systems - e.g. item 275 showing a parent_id of 2 instead of 274. There were other errors around these menu items as well.

This is the first time I have modified the database myself. Previously any updates have been done by Joomla itself or the extensions I have installed. Given that the only extensions I've got on one of my sites are JCE, JCE MediaBox and a template (which definitely doesn't modify the database) it looks to me like the original problem was down to Joomla.

I can close this item on the basis that I've fixed my problem. However, my view is that it would be good if there was something (possibly the rebuild menu function) that checked the default Component menu items were all present and correct, and could fix any problems with these items. It would also be good if the rebuild function checked for orphan entries as they can clearly cause problems since rebuild won't touch their lft and rgt values.

Thoughts?

I have the same problem. One of my sites is totally messed up by this. Menu items depublish by themselves and I can't publish them again. If I try to make the whole structure of that menu-item again with sub-items it's not possible to publish anything. It's since the upgrade to 3.7 and the message "Failed publishing 1 menu item as at least one of its parents is unpublished or one of its children is checked out." keeps showing.

How can I resolve this?

If it is the same problem I had, at the moment the only way to fix this is to modify the menus table manually. There is nothing currently in Joomla that will fix it for you.

How many rows has your menus table got?

Thanks for responding!
There are 342 rows there... Could clean op 30 of them but the rest is being used.

Does it help to change te version back to joomla 3.6 ?

@YvVz Run this query in phpmyadmin

SELECT  `published` FROM  `#__menu` WHERE `alias` = 'root';

replace #__ with table prefix and show result.

SELECT published FROM #__menu WHERE alias = 'root';

Ran the query. Nothing happens. No result was shown and nothing has changed in functioning

Remember to replace #__ with value of $dbprefix from configuration.php.

Thanks wojsmol, but ofcourse I did that.

Only thing dat show is this:
Generation Time: Jun 19, 2017 at 02:46 PM
Generated by: phpMyAdmin 3.5.8.1 / MySQL 10.1.22-MariaDB-1~xenial
SQL query: SELECT published FROM j25_menu WHERE alias = 'root' LIMIT 0, 30 ;
Rows: 1

Plese attach scromshot

@YvVz What is the name of the menu with which is the problem? Maybe menu or main?

It's "mainmenu"

@wojsmol any further suggestions because of the name?

@YvVz The problem may be bad data in table #__menu as in @prh47bridge case, but to thoroughly check I would need to see the dump of this table - as a sql file.

Hope you can help me @wojsmol. Thanks in advance. Here's the dump (I changed site name in it).

sql.txt

@YvVz i have just moved your SQL to a text file that way we don't have that very long comment ;)

Hi @zero-24 Sorry, I was trying to change it, but you were way faster :) Thanks

@YvVz After importing the table from the attached dump to a clean Joomla! 3.7.2 Creating new main menu items works fine. Keep in mind that if an menuitem is unpublished then All of its submenu will be set as unpublished on save.

I don't understand really what you're telling me. So there isn't a problem with the table? Because my site still has the problem. The error also says that a menuitem is unpublished, but there isn't. Just like there wasn't with the other people with the same issue. And now I can't even make new ones (without any subitems) to publish.

@YvVz Give me the name or id of the menu item with which you have a problem.

@YvVz You've got bigger issues that need attention in your menu table right now. Long and short is you've got data corruption. Using this screenshot as a point of reference...

The highlighted menu items are for the admin menu. They have a parent item going to a frontend menu item. On a cursory glance, I also see that the nested tree structure is very broken with menu items for frontend items being in the tree under an admin menu item and various other aspects of those child frontend items are broken as well (the parent ID not matching what is actually in place, or the tree level).

Unfortunately it looks like you've got several problems in your data structure which could be causing your issues.

@mbabker I've seen this kind of problem after update to 3.7.0.
@YvVz You have a backup of the database before this update, pull out the table #__menu and add it as a file - for comparison purposes.

@mbabker Would it be solved if I de-install the banner-component? I'm not using it.
In the meantime I've build the menu-stucture under "activiteiten" from cratch. That worked, so the problem for now seems to be solved, but I'm pretty sure it will happen again with another menu-item (this was the second time it happend).

I have the same issue ufter update to joomla 3.7.3

@valentinabarbieri Execute this query in phpmyadmin

SELECT  `published` FROM  `#__menu` WHERE `alias` = 'root';

Replace #__ with table prefix and show the results.

I already tried all the solutions here, also this but nothing helps....
tks in advance.... but I have a big big problem now....

plese show reresult - this is debug query not fix.

here my results

@valentinabarbieri See #15938 (comment) Probably true also in your case. If you attache a dump of the #__menu table, then you can look at it.

dont know if i have understand ..... :-D

plese attach as sql file - renamed to txt. In the screenshot you can not see all the required fields.

di29r_menu.txt
this way ?

I have made a test I give "default" front page to a new menu item article....
here is

the result

@mbabker When downloading file from @valentinabarbieri I get XML with AWS error

The request signature we calculated does not match the signature you provided. Check your key and signing method.

plese help
@valentinabarbieri As you cen see I cen't download your file.

http://www.zfactor.it/menu.txt

I do not know
"The request signature we calculated does not match the signature you provided. Check your key and signing method."
what is it ?

This is infeastruuctural problem. Nothing you have to worry about.

I find the solution at my problem
into backoffice in "all menu items" "administrator" selecting trashed items I found old component menu items I empty trash and empty also all the site menu items inside trash
after that all worked
Thank you very much for your help!

I am closing this as it would appear to be resolved

Had the exact same issues mentioned above. Even got the same SQL error when putting into phpMyAdmin. Using SiteGround's Joomla installer with sample data I received this issue with a fresh install of Joomla. The only thing I did was change the default menu item to a featured article view. After doing this I couldn't re-publish the homepage (hence the 404) no matter what menu item type I assigned, there was nothing in the menu item trash, and the Joomla database fix button didn't fix the issue.

The solution in my case was to swap the main menu item to another one, delete the menu item with this error.

I upgraded to 3.7.5 a few days ago. I made a change to a category, now it wont publish, however, there is no error message. It just says published:

@michaelbravo777 On the fronted this category works or not? I wonder if it's just a matter of showing category status in backend.

Getting a 404 on the frontend. If I publish the category on the backend I get a message saying "1 category published" however the category still has the red unpublished icon next to it.

There is an explanation for this, you can find the error at the log file

Since this issue is closed

i have opened an new issue which also has an explanation of why this is happening
#17808

In my case the issue was Menu_Item_Root was unpublished (dont know how) in table _menu

Can we please stop using the Issue Tracker as a support platform? This should have been referred to the forum imho?