Custom Dashboard / Backend Pages

Assume as an example that I wanted to create a subpage for the Pages section of Dashboard for some tool or purpose. (external tool embed showing stats for group’s pages, )

Is it possible to do the following?

  1. Define the content of a new backend page. (i.e. /livewhale/?pages_tool)
  2. Add a subnav item (or main nav) for that backend page in an appropriate place.
  3. Limit the visibility of the page and nav items to specific groups or permissions.

…and if so, what is the best practices around this kind of development?

I am particularly interested in the possibilities of #1 and #3.




Additional Context

I’ve addressed #2 and #3 somewhat previously using a module onOutput using str_replace to sneak in some additional navigation items for the Registrar’s office.

For the main links of these sections, like “Course Data” under Courses, I added links to previews of widgets. That works, but the ideal would seem to be able to make a backend page which shows that widget (or similar output in an alternative approach) within the Dashboard UI, rather than linking out to a widget preview.

Specifically, I’m interested in making an additional backend page under Groups & Users where I can define a dashboard to help me better manage editors using custom fields I recently added. The exact what/why of that would be an entire separate thread, but in brief, I want any such Users resource to only be accessible in (#2/3), and ideally integrated into (#1), the Backend.

I think maybe you can drop your PHP script in /livewhale/private (at the web root) and that will create a backend page at that URL. I don’t know if that is the best practice, but Karl once dropped a script in there for us that imports redirects from a CSV file. I modified the script a little bit too and it works great.

The file is formatted like…

<?php
require $_SERVER['DOCUMENT_ROOT'].'/livewhale/nocache.php';
echo '<div class="main no-sidebar"><h1>Import Redirects</h1>';
/* some PHP code */
echo '</div>';
?>

I don’t know how to associate the page with a specific nav/subnav, but like you said, you could probably handle that with a custom module.

Support may have better options than this, but that is my limited experience in this area.

I poked at that, and while it may work, the folder appears to be publicly accessible. I put a file in it (https://www.beloit.edu/livewhale/private/folder-public-test.php) to test, and I can see it while not logged in.

(@karl This may be a concern! I see what appears to be old support testing files in that folder, some that may submissions or edit the database; seems a bit risky having those in a publicly accessible folder.)

I think I did find what I wanted after a bit of poking around: /livewhale/client/modules/catalog/templates/private.catalog_export.html

This makes a page as hoped: /livewhale/?catalog_export.

My next issue is getting the content I want there… especially when that content is currently in a widget. -_-’

<div class="main">
  <h1>Catalog Output</h1>
  <p>Catalog Output Content Should Follow</p>
  <widget id="602_profiles_catalog_output_html"></widget>
  <p>Right...widgets might not work in the backend... *sigh*</p>
</div>

I’d rather not have to rework all those widgets into a PHP process. In any case, good to know this is an option.

Any /private/ files we’ve created typically begin with require $_SERVER['DOCUMENT_ROOT'].'/livewhale/nocache.php'; so (a) you have access to the $_LW object, (b) they get the back-end header and footer, and (c) they do require login. But, you can feel free to delete or .bak out any old support files from that folder, or let me know if we can say more about that piece.

And, heard on widgets not being embeddable on the back-end. We’ve run into this recently too with some of our own logging/help docs and it’s something we may explore changing in the future.