envs.lclark.edu Admin HowTo

Here are tips for admins on how to use this multisite. Check back frequently for updates!

The envs.lclark.edu multisite

Server

• We are using a rather powerful InMotion VPS server, yet they will need to tweak it to serve our needs. Please monitor performance, both front-end (i.e., viewing pages while logged out) and back-end (i.e., doing work while logged-in).
• Everyone can help by simply documenting exactly what they were trying to do, and when, if slowness or errors occur, and reporting to Jim Proctor. InMotion technical assistance comes for a fee, but so far their services have been high quality.

Server cache

• We speed up the website via two server-side caches, which mysteriously work together: NGINX and WP Super Cache. Remember that caching also typically occurs in a user’s browser.
• In all cases, a saved copy of pages, images, etc. is served much more quickly than the original from the server database or uploads directory…that’s the point of caching. But it does mean that occasionally some updates aren’t reflected on a page, thus this information to know how to manage.
• We edit NGINX in two ways: (a) it’s configured via the cPanel Cache Manager, which is not available via our WP dashboard; and (b) the NGINX Helper plugin, available to network admins…this basically just includes settings we rarely change, plus ability to purge (but not turn off) cache.
  • May 2020: I’m not finding that the purge function on admin bar or plugin works as well as purging page directly via cPanel Cache Manager.
  • Jul 2020: InMotion tech support came in and tweaked these settings a bit; it’s possible that NGINX was slowing the back-end considerably by purging their entire cache each time a page was updated. Let’s continue to monitor back-end time and tweak NGINX as needed.
• We have Super Cache configured via the Expert option; all settings are here, available to network admins, with Expert settings as per Advanced tab. We are still figuring out how to optimize Super Cache given NGINX, but these settings appear ok for now.
• You can manually remove any page from the caches (assuming you are logged in as network admin) via Delete Cache (Super Cache), then Purge Current Page (NGINX) links on the top admin bar.
• If you need to test certain coding or other changes on the site, it’s best to disable both server side caches. Make sure to enable when done!…caching sure speeds things up.

Overall organization

• The multisite consists of a home or root site, envs.lclark.edu, and a set of course-based subsites, e.g., envs.lclark.edu/220.
• Course sites contain work from current and former iterations of the course, organized by (standard post) categories; e.g., coursework for ENVS 220 spring 2020 is done via subcategories of envs220sp20, the root category. We use the post category as our default taxonomy for CPTs as well.
• Course site work aggregates onto course home pages…see below.

Home page

• At present, the course home pages simply display most recent posts using a Beaver Themer Gallery layout. Other course resources (including CPTs) are available via the menu.
• As of Aug 2020, the root site home page will link to each of the five core course sites, rather than dynamically aggregate content from these sites.

Style

• The site builds on the Genesis Essence Pro theme. We could add home page banner images to this theme, which are randomly rotated and used if no featured image; but at present we are using the ENVX texture, developed for us by PubCom, as our default header and footer. [Footer has issues with light or dark text, however.]
• The font and colors we are using so far:
  • We are sticking with default font from Essence Pro, but modified heading sizes via Customizer CSS.
  • Links use the official LC orange (hex #F36F21), with black rollover, and Essence Pro defaults (e.g., bold).
  • We’ve played with white/light gray text against a blue background matching the LC LiveWhale blue (#003366). This blue seems to work nicely with orange.
• Style (CSS) edits are done via the Customizer page, with details coded via Additional CSS. The multisite also uses Design Palette Pro to readily achieve CSS edits in an easier, WYGISYG interface.
• Most pages and posts use the right sidebar. The Multiple Authors widget displays one or more authors for student-authored posts and CPTs, with avatar and link to their portfolio (author archive). A standard setup would include Authors at top of sidebar, then Post Categories (displaying e.g. those from current semester only), then Recent Posts.
• The sidebar can be modified for CPTs, e.g., to display other records (posts) from this CPT. To do this:
  • Create a new sidebar area via Appearance > Sidebars, and specify where you want it to display.
  • Add widgets to this new sidebar area as usual.
  • If you want to add other records/posts, the Recent Posts with Thumbnails widget won’t recognize CPTs [I may replace it on the multisite]; the Pro version is called Ultimate Post List Pro. The output looks just like the standard Recent Posts widget, but you have to define it in a totally different way.
    • Go to Ultimate Post List > Add New to define your CPT posts list. It has a gillion options!…alas.
    • Then drag the Ultimate Post List widget to your sidebar, specifying the one you developed above.

Multisite content

Root site and subsites

• The root site currently exists primarily as a landing/launch page. It includes an About, and simple links to course sites on header menu. It also has the (published but unlinked to menu) page envs.lclark.edu/adminhowto—this page right here!
• Subsites are where the content really is. They generally include regular and custom posts: regular posts are just that, whereas custom posts allow us to develop course-specific databases, similar to what ENVS has done in past, for e.g. areas of interest or capstones. Subsites can also include pages for About and etc.
• Subsite content is organized via post categories, which cover both regular and custom posts (bel0w). Remembering that sites are used for multiple iterations of a course, the hierarchy of categories would be like this example:
  • ENVS220Sp20 [an RSS feed of this category is thus a feed of all course content]
    • Some post category [e.g., Updates]
    • Another post category [e.g., Event A]
    • Some CPT category [i.e., CPTs use post categories, not separate taxonomies]
    • Another CPT category [e.g., Project Database]
  • Practice posts [another root-level category; thus won’t be included in any course-based post archives. You can exclude this or other categories from your home page, feeds, etc. via Settings > Category Excluder]
  • ENVS220Sp21 [eventually, and etc.]

Posts

• Posts can be used however the instructor wishes, of course, but I initially envision special, occasional posts, typically done by small teams of students, to communicate updates on what is going on in courses to the larger public audience.
• Each site also has a Practice Posts category outside of the course parent category. Practice posts are just that, and are not generally displayed on the home page via Settings > Category Excluder.
  • We can readily add other kinds of posts simply via new categories. Please do so!: it allows us to display particular posts, e.g., from a certain assignment or a certain event, separately.
• The Gutenberg block editor appears to present too many options to students!…if this problem persists, see here and configure this plugin per site to fix.
• More generally, the post interface is quite busy. There are ways to simplify it summarized e.g. here. Also, via Options (bottom of three dot menu) the user can choose to show/hide boxes as desired.

Custom post databases

• We have long utilized WordPress custom post type (CPT) functionality, most recently via Toolset, to develop course databases. Database fields can be readily created/displayed as per instructor preference, but should ideally abide from year to year.
• Here are the databases I envision for each course.
  • 220: Areas of interest; situated projects
  • 295: Engagement partners; engagement projects
  • 350: Theoretical frameworks
  • 400: Capstones

Managing (and quickly assessing) student content

• Student content includes user/author profiles, regular posts, custom posts (forms), and related media. All require routine oversight on these shared websites so as to avoid bloat, redundancies, etc. Additionally, the below may assist in routine/quick assessment.
• One important way to manage content is via dashboard summary pages (e.g., viewing all posts for a course). The columns displayed on each view can be edited via Settings > Admin Columns. This allows for quick management/assessment, e.g., to make sure users have established avatars and bios in their profiles, or to check media that are not attached to any post.
• Another thing to manage are media: students often do multiple unused uploads, for instance. Though the standard media interface seems to suggest those that aren’t being used, a more sophisticated approach will ensure that only truly unused media are removed. This multisite uses Media Cleaner Pro for this; here is a tutorial.

Editorial oversight

Overview

• envs.lclark.edu is designed to connect our students’ work with the public. This demands good quality content!…and thus some editorial oversight.
• The multisite thus includes the PublishPress suite of plugins for editorial management.
• The editorial process is intended to serve two goals:
  • Help students build skills in editorial workflow, typical of many publications/websites
  • Help each other produce quality public content on behalf of the ENVS Program

Editorial options

• The easiest option, requiring no oversight by others, is Checklists; to use it, activate the PublishPress Checklists Pro plugin. This feature requires (or recommends) that each post minimally do certain things before it can be published. The simplest I’d recommend in our case include:
  • A minimum word count
  • Checking at least one category (it can’t check for the correct category, but this at least is a reminder)
  • Attaching a featured image (again, it can’t check for a good, high-resolution, copyright released image but at least it’s a reminder)
  • The above are automatically checked by WP, but you can add other items that students check before publishing. One I recommend is “Final Publish Approval,” a box the author themselves check when they’ve been given the green light to publish.
• Another option is Editorial Comments, where editors (fellow students, ENVS student workers, or the instructor) comment on a post prior to publication; to use it, activate the PublishPress plugin. The process would go something like this:
  • Instruct students to prepare posts, but keep them in draft vs. published status. (This could be also required via Capabilities, such that certain user roles (e.g., Edit0r) are needed to actually publish a post.)
  • The editor(s) then come in, read the draft post (by editing it), and comment on it in the Editorial Comments box below the draft post. Authors will receive comments via email, and can make revisions and reply to these comments, to ensure that each has been attended to. Then editors can go back and confirm that (a) changes have been appropriately made and (b) [this helps with (a)] changes have been documented in the authors’ reply in Editorial Comments.
• Here is one possible workflow:
  1. Draft post text (not yet images, block content, etc.) in GoogleDocs
  2. Fellow students, student workers, or instructor comment on or suggest edits to draft post text in GoogleDocs
  3. When good, copy/paste text into WP post window. (Good news: the Gutenberg block editor supports seamless text copy/paste from GoogleDocs!)
  4. Then add images, blocks, etc. for almost-final version. Include Checklists as above, with additional “Final publish approval” item not yet checked.
  5. Editors then use Editorial Comments window below post (edit window) to note final items to be attended to, and author(s) make changes, then reply (in Editorial Comments window) to comments. (This last step is important to make students accountable, and super helpful for editor to verify that requested edits have been done.)
  6. Once editors/instructor give final approval, author(s) check “Final publish approval,” then publish!

User management

Adding new student users

• Using this Excel template, enter complete information for all students in a course. When done, save in .csv format.
• Confirm settings in WP User Avatar > Plugin Settings. We upload user avatars to a default custom directory, not the site’s media library, so as to avoid bloating the common media library. We then crop to 300×300. We also allow Gravatar if user has one tied to their LC email address (relatively rare). In general these settings are good to go. (This and other avatar plugins, btw, only work site by site; the avatar is unique to each course site, though user metadata are shared across all sites. One final note: as of Fa20, the pro version of this plugin has been acquired by another developer…not sure of continued support.)
• Then go to Tools > Import and Export Users and Customers on your course site. You’ll do two things. First, click Mail Options at top. We currently deactivate both user created/edited emails and password change emails to user so as to avoid confusion. Edit the email template below for your particular course site needs.
• Second, go to the Import and Export… > Import tab. Attach your import CSV file created above via Choose File.
• Make sure to do the following!
  • Click Author as default role
  • Enable “Do you wish to send a mail with credentials and other data?” and “Do you wish to send this mail also to users that are being updated?” [so those already on the multisite get a reminder/opportunity to change password/etc.]
  • If there is a possibility that you are uploading a student already on the site (e.g., who is taking/has taken another ENVS core course), edit the “Update Users” options to say “Yes” for update existing users, and “Yes” for updating their roles.
  • Do not check the “Users not present in CSV file” options!…you’ll, um, delete the existing users.
• Then click “Start importing” and you should be set! If you want to verify that confirmation emails were sent ok, go to Post SMTP > Email Log.
• Note that users are site-specific, though network admins can manage users at the multisite level. Note also that user data are shared across all sites, though local (non-Gravatar) avatars are not.

Adding/managing admin users

• Users have privileges according to role. Students are generally Author role. Each site can have Admin role users who can do all admin on the site. Network Admin (or Super Admin) role allows admin on all sites, plus some network admin privileges.
• Admins can be added directly, or a network admin can edit the user and change their role on that site. In the network admin panel, a network admin can enable the user to be a network admin too!…but use this feature very, very selectively.

Users and authors

• All user profile information is presented to students e.g. here. In general, user profile information is stored across the multisite, with the exception of uploaded avatars (i.e., not Gravatars), which are local to a given site (the one plugin that used to support multisite avatars is no longer supported).
• User profile info is displayed, with layout determined via the PublishPress Authors plugin, on author archives (porfolios), with respect to privacy in two possible ways:
  • In general, similar to what the LC site does (and former ds.lclark.edu site did), non-logged in users see only the student’s first and last name (and avatar); whereas logged in users (i.e., fellow students/instructors/staff) see additional details, including email, bio, and optional website.
  • Students can indicate Yes in a share information variable on their author profiles that will make their bio, email, and website available to public (non-logged in) visitors.
• Updated user profile data are not automatically synced to author profiles, esp. their bio and/or website URL. We can fix this periodically via Authors > [select all] > Bulk Actions > “Update data from mapped user.”
• We have installed the PublishPress Authors plugin, in part so that multiple users can claim authorship for one post…a big divergence from standard WordPress.
• One possible point of confusion with the Authors plugin is that, by default, author-level users can see/edit authors on the dashboard!…they should only be able to see/edit their user profile.
  • The fine print: PublishPress Capabilities (as would other user role management plugins) allows you to disable “ppma manage authors” for author level, thus hiding the Authors items on the dashboard, but this also disables ability to add/edit post authors and edit one’s author profile custom fields, so we need to leave it on.

Author portfolios

• The Authors plugin summarized above supports more-or-less automatic portfolios students can use to evidence their work on each (separate) course page. [Note: in rare instances students check “Enable Author Box on this User’s Archives?” when editing their user profile, which disables the Authors profile!…just uncheck and it will work.]
• Portfolios can include:
  • User avatars
  • User bios [displayed to logged in users only, or if Author profile indicates Yes in “Information sharing.”]
  • User emails and websites [see above re. privacy]
  • Custom fields, e.g.,
    • User-supplied course overview
    • User links to CPTs
  • Portfolios automatically include summaries of all posts for which user is listed as co-author
• Aug 2020: Authors plugin now supports new conditional code we can use to automatically check if author has published a certain CPT and, if so, display it; this obviates current Authors custom field in which they need to enter URL of CPT. We hope to implement by Fa20.
• All authors can be displayed on a single page via the Authors List plugin, e.g., like this.

User support

User login

• As noted above, users (i.e., LC students) login using their LC email prefix as username.
• Users set their passwords upon registration, and can change them at any time on the login window (e.g., if they forgot their password). An admin can also edit their user profile and change their password if needed.
• The multisite initially had a plugin called Limit Login Attempts, but in spite of its WP popularity/ratings it didn’t play well with our configuration and password managers, so now I’ve installed a CAPTCHA plugin that is set to kick in after two failed logins—a light, but far better than nothing, security solution. (CAPTCHA settings are done site by site.)

User privacy

• As discussed on user help pages (e.g., here), by default only the user’s display name is publicly available, similar to the LC site, where the names of all students is available via search. We also make the user’s avatar public, as the user can choose what they wish their avatar to be.
• An information privacy variable in the Author profile allows users to share their bio, email, and website URL with public (non-logged in) visitors. This information is shared by default with all logged-in (i.e., fellow student) users.

User interface

• The logged-in user interface, with admin bar at top and dashboard menu items at left, can get busy/confusing, and some plugins not relevant to author-level users (i.e., students) are still visible on the dashboard menu (though, typically, nonfunctional).
• A great deal of this can be cleaned up via Settings > Adminimize. Adminimize can selectively hide items for particular roles. In our case, we’d hide items from all with the author role.

Help pages

• Help pages are handy ways for users to learn/remember what to do.
• One example in here on the ENVS 220 site.

Logging in as a user

• If you wish to diagnose things from a student’s perspective, you may view the interface as does any particular student by going to Users > All Users, then rolling over a user and clicking the Switch To link.

Appendix: Plugins

Aug 2020: We can maintain a list of plugins here, to be incrementally brought up to date/updated. In general, important plugins are network activated (unless they clutter the logged in user interface, thus activated as used per site); also in general, non-network activated plugins not activated on any site at present are either unneeded or needed only occasionally.

Administrative

These plugins are to assist with administration of the multisite. Most arose to serve some specific need.

• Admin Columns Pro:
• Admin Columns Pro – Toolset Types:
• Bulk remove posts from category:
• Check Email:
• Code Snippets:
• Error Log Viewer by BestWebSoft:
• Genesis Simple Edits:
• Media Cleaner Pro:
• Media Library Assistant:
• Multisite Enhancements:
• NS Cloner – Site Copier:
• Really Simple SSL:
• Sort My Sites:
• User Switching:

Blocks

Plugins related to the Gutenberg block editor. They may be too many!: let’s consider how students use them. As of Fa20, see Block Manager plugin to remove extraneous blocks and focus student use [implemented on 160/350 sites].

• Advanced Gutenberg:
• Atomic Blocks – Gutenberg Blocks Collection:
• Ultimate Addons for Gutenberg:

Custom post type

These plugins facilitate create/management/display of CPTs. Here is summary of Toolset components.

• Toolset Access:
• Toolset Blocks:
• Toolset Maps:
• Toolset Types:

Display

These plugins assist with desired front-end (or, in rare cases, logged in user back-end) display. Here too, most arose to serve some specific need.

• Adminimize:
• Authors List:
• Display Categories Widget:
• EmbedPress:
• Feedzy RSS Feeds Lite/Premium:
• Genesis Dambuster:
• Genesis Design Palette Pro:
• MapPress Maps for WordPress:
• Recent Posts Widget With Thumbnails:
• Send Images to RSS:
• Sidebar Manager:
• Ultimate Category Excluder:
• Ultimate Post List Pro:

Editorial

These plugins are for editorial control of published content, all derived from PublishPress.

• PublishPress:
• PublishPress Authors Pro:
• PublishPress Capabilities Pro:
• PublishPress Checklists Pro:
• PublishPress Permissions Pro:
• PublishPress Reminders:
• PublishPress Revisions Pro:

Page builder

These plugins provide page builder functionalities, all derived from Beaver Builder.

• Beaver Builder Plugin (Pro Version):
• Beaver Themer:
• PowerPack for Beaver Builder:

Server

These plugins relate to our server as a context for our WordPress multisite.

• Nginx Helper:
• Post SMTP:
• Query Monitor:
• Really Simple SSL:
• WP Super Cache:

User management

These plugins are for direct operations affecting logged in users. Here too, most arose to serve a specific need.

• Advanced noCaptcha & invisible Captcha:
• Import and export users and customers:
• Unconfirmed:
• When Last Login:
• WP User Avatar Pro: