Header menu troubleshooting #

You added a node ID to MainMenuID[] and the header did not change. Check these in order; each one was seen while writing these pages.

Contents #

1. The compiled template still has the old list
2. The page cache serves the old page
3. The value went into a file that does not win
4. You changed another siteaccess
5. The node cannot be fetched
6. Velocity workers kept the old settings
7. A quick check list

1. The compiled template still has the old list #

The most common cause. pagelayout/header/main_menu.tpl reads the list with ezini(), and the template compiler writes the values into the compiled file under var/<site>/cache/template/compiled/ (a file named main_menu-<hash>.php). Saving the setting clears the INI cache, not the compiled templates, so the old list keeps being shown.

On the test copy, after saving =192: clearing the INI cache, the content view cache, the template block cache and the page cache each left the menu unchanged; clearing the template cache brought the new item at once.

Fix: administration Clear cache > Template & content > Clear, or ./console exp:cache clear --tag=template,content. Once on the test copy (for the footer list), a page rendered between the setting change and the clear kept the old list after the first clear; a second exp:cache clear --tag=template,content showed the new item. Clear again before looking further.

2. The page cache serves the old page #

Pages are kept in the HTTP page cache (cache id exphttpcache). A response header shows it:

X-Exp-Cache: HIT
Age: 9

The tags template and content both include exphttpcache, so the fix in 1 clears it too. Alone: ./console exp:cache httpcache clear.

3. The value went into a file that does not win #

MainMenuID[] is set in more than one file. On the Fit & Healthy site the theme extension sets five IDs, and settings/siteaccess/site/menu.ini.append.php starts with MainMenuID[] (the reset) and sets its own. A value added to the extension's file is dropped by that reset. Check with:

./console exp:ini where menu.ini/SiteInfo/MainMenuID site

The administration shows the same under Set in 2 files, 1 overridden. Write to the file marked "elements in effect" (scope siteaccess:site).

4. You changed another siteaccess #

The site site and, for example, bold or eng each read their own menu.ini. On the settings page the Siteaccess choice decides which one you edit. The siteaccess of a page is the one its address matches (host or first path element); ./console exp:ini where ... <siteaccess> shows each list.

5. The node cannot be fetched #

main_menu.tpl skips an ID whose node cannot be fetched, without a message. Causes: a typo in the ID, an object ID instead of a node ID (the admin shows both: Node 192 · Object 190), a page in the trash. Open /content/view/full/<id> in the administration to check the ID.

6. Velocity workers kept the old settings #

On a site served by Exponential Velocity, exp:ini prints: Velocity workers keep the settings of their warm-up: exp:velocity restart to apply it there. After the cache clear, run ./console exp:velocity restart on such a site.

A quick check list #

1. ./console exp:ini get menu.ini/SiteInfo/MainMenuID -s site lists the new ID.
2. ./console exp:cache clear --tag=template,content ends with PASS.
3. The page source has menu-item-main_menu-location-id-<new id>.
4. Velocity: restarted.

Related pages #

• Caches after a change
• Why doesn't my change appear?
• Add a header menu item
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.