Yes of course @ ctgraham, a Static Page so the paths of Static Pages can’t be appended a “#”. Thanks for the plugin path, however, I was able to append a # to the path of the Navigation Menu Added items. It works without editing any files including those two files that you mentioned: PKPNavigationMenuItemsForm.inc.php#L209 and StaticPageForm.inc.php#L46. Maybe it works because OJS3 asks for entire URL for an Added Item, but only the path/slug for a Static Page? That seems the only interesting difference, in the backend at least.
But unlike for Static Pages (won’t take anchors) or for Navigation Menu added items (will take anchors), OJS3 doesn’t make the paths of Navigation Menu internal items/links available in the backend for display or editing. Appending #nav-menu to those links via your file NavigationMenuItem.inc.php#L60 didn’t work either (I tried all variants for concatenating two strings I could think of). Even the removal of that entire line has affected no internal items/links in the Navigation Menu, so those default links still generate normally. That made me think if I am in the right location: /lib/pkp/classes/navigationMenu/NavigationMenuItem.inc.php ? (But then, removing of that file crashes the site so this seems like the right location after all.)
–
I found a simple solution to the OJS force-redirect from missing files/folders to the OJS generic 404 message when restful_urls = On in config.inc.php (instead of redirecting to a custom 404 page), so that the expected .htaccess redirect doesn’t happen even when a custom 404 page is present. Instead of trying to make the string on line 252 of your file Dispatcher.inc.php#L247-L253 more user-friendly and stylish, just replace the line 251
header('HTTP/1.0 404 Not Found');
with
header('Location: /404.html');
where 404.html is your custom 404 page (here in the OJS root). The extensions can be .htm, .html, ,shtml, .php.
While reading the PKP forum I noticed somewhere that this 404 issue has been raised in the past, but was marked low priority. However, given how simple it is to resolve, you may wish to implement it in an upcoming update, or as a specs comment at least.
–
Your class(es) for changing the site-wide alert’s background color from #d00a6c to something else, didn’t work - not even with the !important flag after clearing all the caches (browser’s as well as all three OJS’s) and re-logging, see the Submissions deletion alert for example - the color still pervades in both background and button text styles:
