How to reset main menus but not custom menus

I upgraded LibreOffice from 5 to 6, but I have a document with a custom menu for running some macros. When I load that document the window arrangements revert to the version 5 layout. I can go to Customize and reset the menu, but that wipes out the custom menu(s) I have made. Isn’t there some way to preserve the custom ones while reseting the default ones? I don’t see even a way to export or custom import menus.


There are dozens of places menus are stored within LO. Menus do have a default location and locations for customized menus depending upon type and module. Default menus are stored in folders with the installed LO application. A menu customized at the application level is stored in the appropriate folder in the User Profile. A custom menu for a specific document is stored in an appropriate folder in the compressed file of the document. When dealing with base and some other specifics within other documents there are special menus which can be modified and those are in their own folders.

So in order to give any specific help, it is necessary to know some more information. What specific version of LO are you using? What OS? What document menu are you talking about - Writer, Calc etc.? Is the menu at the application or document level?

There are certainly ways to have custom menus at the document level while have default menus at the application level (new documents). In Base you can have a different menu for every Form. It all depends upon the setup performed.

If you want to do some of your own checking the default folders are in the directory where LO was installed under:


where X.X is the installed version of LO.

For customized menus at the application level they are in the User Profile folders under (hidden folder):


And for customized menus at the document level they are within the compressed file in :


Each of these have sub-directories for the specific module and further sub-directories for the type of mod (menubar, popupmenu, statusbar, etc.)

The actual files typically all have the same name - menubar.xml. So where they are located is critical.

Bottom line, it sounds as if you created custom menus at the application level when you probably should have created them at the document level - this is the Scope choice when creating the custom menu.

Edit 2018-10-02:

Custom menus are not always clear cut. Don’t know what type of document you are dealing with but let’s use Writer as an example.

When you set a custom menu while this document is open, the dialog presents a choice as to what menu will be changed: this is the Scope setting. The choices in the Scope dropdown are for LibreOffice Writer and any xxxx.odt files you have open at the time. If you choose LibreOffice Writer you are setting the menu at the application level which overrides the default menu. Choosing xxx.odt will change the menu only for that document. Any menu changes made should be realized immediately upon closing the dialog - no need to close the .odt & re-open.

When you set the custom menu at the application level, in the above case ALL Writer documents now will show this new menu. If you have a custom menu set at the xxxx.odt (document level) that takes precedence over any custom application or default menu. So the priority of menus is:

Custom Document menu - xxx.odt - stored in the compressed .odt
Custom Application menu        - stored in the User Profile
Default Application menu       - stored in the installed program directory

As stated earlier, there are many other menu types and can be stored in different folders within those storage areas.

Not knowing what you have specifically done when you actually created the specific custom menu(s), it cannot be said where your problem remains. You may possibly have custom menus for application AND document levels or one or the other. Not knowing this makes it a guessing game as to how to repair/correct your situation.

Thanks. Sorry, when I said “custom menu” I just assumed document level. Well, I did say “I have a document with a custom menu…” in my question.

It seems like a bug to me that having a custom menu in a document would interfere with all the other menus and cause them to not update when you update LibreOffice… Anyway, I guess you are saying that if I want to preserve or transfer menus from a document I should unzip it and copy out the menubar.xml and then inject it into another document?

(or into the same document after resetting the menus?)

Oh, maybe if I reset the menus and then just re-open the document, the custom menus will return?

If menus are set properly when created, there is nothing to change or copy when upgrading a version of LO. Please see my edit in the answer.

I have been using custom menus for years without a problem.

What may be helpful is knowing if you have a menubar.xml file in:


where xxxx = swriter if Writer doc, or scalc if Cal doc. Then if there is another in the compressed file under /Configurations2/menubar/.

You still have not given ANY details about what you are dealing with as asked in the original answer.

I already said the menu is at the document level. And I already said I was upgrading from 5 to 6. It is in Writer, but I don’t think that matters. I am using Windows 10, but I don’t think that matters.

Anyway, it is impossible to test any solution now, because I already reset the menus in LO and they all look correct now, no matter what document I open. I had to rebuild the custom DOCUMENT LEVEL menus in my problem document. Or at least I thought I had to. But maybe if I had just opened a blank and reset the menus from there, then I could have opened my problem document and the standard menus would be updated without losing the custom menus in my document.

But that still leaves the question of why the document didn’t show the updated menus in the first place, after I updated LO.

@lomacar It is good you now have acceptable menus. Unfortunately, answering you question cannot be done without knowing in which folder that custom menubar.xml file was located. You may not completely comprehend, but knowing which module was being used & on which OS does have a bearing on where this file may be stored.