main/index.php's default view (no _action) is a single HTTP response containing several visually distinct panels: an optional admin-configured welcome/notes block (home_page_title/home_page_notes, settings row journal_code = 0), a quick keyword-search box that submits to ?_action=article, and the full journal-directory grid. The journal-directory panel is catalogued as the Journals module's own "Journal Directory" row, and the search box's destinations (results/author/advanced search) are catalogued under the Articles module — both of their pages explicitly cross-reference this row as "the Landing module's home screen." "Portal Home" above is what remains: the page shell, the optional welcome banner, and the search box as a widget (not its results). All three rows legitimately share the identical main/index.php legacy ref/route by design.

The assignment brief's suggested anchors resolve elsewhere: class/index.class.php defines IndexManager, the per-journal "indexing services" (DOAJ/Scopus-style) CRUD reached from the role-portal's manager.php — unrelated to the portal home page. main/index.php is a monolithic script with no class/view layer of its own; every branch above is an inline if/elseif in that one file.

main/header.php renders a nav link for each non-empty menu1_title…menu5_title setting (journal_code = 0); clicking one hits main/index.php?menu=N, which swaps the main panel for that slot's title/body pair (menuN_title/menuN_cnt). All five slots render through the same code path and are treated as one row.

main/adm.php (Super Admin) is a separate segment's entry point, out of scope here. main/jufile.php, main/robots.txt.php, and main/sitemap.xml.php are non-HTML file/crawler outputs, not screens. main/request/*.ajax.php (editor.ajax.php, tech.editor.ajax.php, page.editor.ajax.php) are AJAX fragment handlers for the Role-Portal Hub's queues below, with no rendered screen of their own — mostly GET requests issued by inc/js/pm.js, tech.editor.js, and page.editor.js (a couple of calls, e.g. pm.js's save-action task, use POST); not POST-only as an earlier draft of this note claimed.

An earlier draft of this note dismissed main/login.php as merely an alternate path to the Super Admin login and attributed main/pm.php to the Publishing Workflow segment's Production Manager module — both wrong. main/login.php unconditionally sets $_PARAMS['pm']=1 (main/login.php:26-27), routing JournalAdmin::adminLoginForm/adminLoginAction (class/adm.class.php:33-44, 97-154) into a materially different branch than the Super Admin login: the role filter is _role IN(5,7,8,11,13,17) instead of _role = 10 (adm.class.php:126), success sets $_SESSION[SESSION_NAME_ID] instead of $_SESSION['juAdmUser__'], and it redirects to pm (main/pm.php) instead of adm. And publishing-workflow/production-manager.html's own note explicitly disclaims main/pm.php as an "old duplicate app tree" built on class/pm.class.php's PMAdmin — a different class than that module's EditorManager — so in fact no page in this inventory covers it. Both files are live under main/ (this segment's own dispatch root — the j.ekb.eg vhost in httpd-vhosts.conf confirms main/ is served, not dead code), so they are catalogued here as Landing's catch for otherwise-unclaimed main/ screens, the same treatment already given to Static Menu Page and Contact Us above.

main/pm.php instantiates class/pm.class.php's PMAdmin (Production Manager Queue), class/tech.editor.class.php's TechEditorManager (Language Editor Queue), and class/page.editor.class.php's PageEditorManager (Page Designer Queue) — a separate, simpler class tree than the canonical publishing-workflow/production-manager.html (root pm.php + EditorManager), language-editor.html, and page-designer.html modules, and missing several of those modules' rows (tech_au/au_tech/handled have no equivalent anywhere in class/pm.class.php — confirmed by grep, zero matches; returned (class/pm.class.php:56) and search (class/pm.class.php:81, inside PMAdmin::getSubmissionList) ARE present in the class and reachable via ?_action=pm&st=returned|search even though main/pm.php's own dashboard links to neither — same undiscoverable-but-reachable pattern as the new Production Manager Report row above (class/pm.class.php:9, 1538, for st=report). The sibling st=track branch (class/pm.class.php:13) delegates to EditorManager::showManuscriptTracking (editor.class.php:4619), which returns early with no output when no manuscript row matches the given manu code, so it is a manuscript-detail fragment rather than a standalone screen and is not added as its own row here). Each queue's own st= sub-filters (pm's new/tech_editor/tech_editor_p/page_designer/page_designer_p/galley_proof/final_accept; tedt's and pd's assign/assigned) render the same filtered-list-with-live-count pattern as the parent queue's own default view, so — consistent with this page's Static Menu Page row — they are grouped under one row per top-level branch rather than one row per filter. Roles 13 (Abstract Editor) and 17 (Supervisor Editor), though admitted by the login gateway's role filter (adm.class.php:126) and referenced inside class/pm.class.php's manuscript-action logic, have no corresponding link on the Role-Portal Hub or a dedicated queue of their own here; flagged as an open gap, not resolved in this pass.

That file also rewrites years.html, list_N.html, rss, and contact.us$ → ?contact, but main/index.php has no code path reading $_GET['years'] (grepping main/index.php case-insensitively for "year" only hits the vi_year DB column), $_GET['list'], $_GET['rss'], or $_GET['contact'] — those params are only implemented in mainn/index.php (a different dispatch dir, out of the Portal segment's scope per the design doc). The contact.us pretty URL is actually served by the real main/contact.us.php file via the generic "append .php" rule earlier in the same file, which fires first. Also worth noting: common/subjects.md describes a "portal home sidebar" that filters the journal directory by Portal Subject (?list=) — that behavior exists only in mainn/index.php's showJList(), not in main/index.php, so it is not reflected as a Landing (or Journals) row here.